По теме из базы знаний
- UsersLog.exe. Система полной отчетности об использовании рабочего времени пользователями. 1С, Word, Excel, Кино, Интернет, Одноклассники, ВКонтакте и т.д. Не только 1С, но и все активные окна Windows посекундно!
- Go. Разбор лога технологического журнала. Достойная альтернатива perl'у
- Руководство по SQL: Как лучше писать запросы (Часть 1)
- Интеграция СуперОкна7 и УНФ
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) serq82, по идеи, если имеются "правильные" индексы на объектах, то тормозов быть не должно. Возможно, будут проблемы если у пользователя назначено несколько ролей с RLS (вплоть до вылета ошибки SQL).
Справедливо сказано (2) что RLS - дополнительные проверки и т.д., но если будешь делать другими способами - тоже будут доп. проверки и т.д. Так вот что бы свести их "тормознутость" (что RLS, что самописных проверок) к минимуму и нужна соотвествующая организация баз (индексы и т.д.).
Как я понимаю, RLS позволяет не прописывать эти провреки везде (во всех формах), а одни раз прописать их в ролях и система гарантированно будет их выполнять. Кроме того в запросе появляется возможность использования "Разрешенных".
Это я все к вопросу о том стоит ли использовтаь RLS или нет :)
Справедливо сказано (2) что RLS - дополнительные проверки и т.д., но если будешь делать другими способами - тоже будут доп. проверки и т.д. Так вот что бы свести их "тормознутость" (что RLS, что самописных проверок) к минимуму и нужна соотвествующая организация баз (индексы и т.д.).
Как я понимаю, RLS позволяет не прописывать эти провреки везде (во всех формах), а одни раз прописать их в ролях и система гарантированно будет их выполнять. Кроме того в запросе появляется возможность использования "Разрешенных".
Это я все к вопросу о том стоит ли использовтаь RLS или нет :)
(9) AlexO,просто в УТ10 используется по организациям,контрагентам,я доделал по складам,кассам,подразделениям,открыли филиал в другом регионе,у них будет человек типо бухгалтера,нужен доступ ко всем документам,но чтобы видел доки и отчеты только своего филиала...работать начали доков еще немного,вот переживаю за будущее....посмотрел в УПП и КА там проверка на различные справочники есть.
(10) serq82,
УПП - самый "доделанный" в плане RLS.
А то, что сами доделали - оно, конечно похвально, но, боюсь, как-бы боком не вышло это вашим пользователям.
Там не так все просто и наглядно.
Тестируйте на всех пользователях и максимальном количестве видов документов (желательно - чтобы сами пользователи ковырялись в доках).
А то вылезет в самый неподходящий момент - и осатнетесь совсем без ограничений, в силу того, что от него придется придется отказаться в пользу работоспособности конфы: надо же будет все-таки хоть как-то - но работать, проводить документы...
УПП - самый "доделанный" в плане RLS.
А то, что сами доделали - оно, конечно похвально, но, боюсь, как-бы боком не вышло это вашим пользователям.
Там не так все просто и наглядно.
Тестируйте на всех пользователях и максимальном количестве видов документов (желательно - чтобы сами пользователи ковырялись в доках).
А то вылезет в самый неподходящий момент - и осатнетесь совсем без ограничений, в силу того, что от него придется придется отказаться в пользу работоспособности конфы: надо же будет все-таки хоть как-то - но работать, проводить документы...
(13) serq82,
а в отчетах - все отчеты будете пербирать? а справочники - везде, где есть обращение к справочнику? а обработки - все обработки будете перделывать? это еще при том, что в доках могут быть и ссылочные значения второго порядка (ссылка через ссылку) "запрещенных" объектов, которые тоже надо отлавливать и проверять на легитимность.
Вот поэтому - (8):
"Если поставлено ограничить ВЕЗДЕ - то только RLS, без вариантов. А если конкретные документы/справочники/регистры - попробуйте через роли и код."
а в отчетах - все отчеты будете пербирать? а справочники - везде, где есть обращение к справочнику? а обработки - все обработки будете перделывать? это еще при том, что в доках могут быть и ссылочные значения второго порядка (ссылка через ссылку) "запрещенных" объектов, которые тоже надо отлавливать и проверять на легитимность.
Вот поэтому - (8):
"Если поставлено ограничить ВЕЗДЕ - то только RLS, без вариантов. А если конкретные документы/справочники/регистры - попробуйте через роли и код."
(7) serq82, (виноват что поздно) посоветую все таки использовтаь RLS, но аккуратно. Это вариант лучше чем перерабатывать все формы и запросы.
Я не знаю, убедил ли вас, по поводу учета индексов, но все таки своветую учесть, и если не врете мне, опять таки отсылаю к литературе по архитектуре данных в 1С и к материалам на сайтах.
Я не знаю, убедил ли вас, по поводу учета индексов, но все таки своветую учесть, и если не врете мне, опять таки отсылаю к литературе по архитектуре данных в 1С и к материалам на сайтах.
(3) Ягг,
что за идеи такие интересные по поводу RLS и индексов? :)
RLS - это дополнительная "развертка" вглубь проверяемых типов данных в целях проверки "на вшивость" (т.е. на легитимность использования), помноженная на количество объектов с проверяемым типом данных в текущих данных, плюс их соединения со множеством всяких дополнительных таблиц (регистры свойств, разрешенией, доступа и т.д. - которые без RLS не задействуются, или используются крайне редко) - отсюда и существенные тормоза.
И чем больше RLS (даже без "несколько ролей") - тем все больше и больше будет обработка данных (для отчетов, открытия документов, выборки из регистров..)
В запросах ВСЕГДА есть возможность использовать РАЗРЕШЕННЫЕ. Только когда RLS не включен - эта инструкция пропускается, а когда включен - отрабатывает. Причем не так, как вы думаете.
И RLS - это не "позволяет не прописывать эти провреки везде (во всех формах)", а проверки доступа на уровне записей в БД. А приоверка в коде - это проверка на уровне исполнения кода (в ветку попало - проверилось, в ветку не попало - не проверилось).
по идеи, если имеются "правильные" индексы на объектах
что за идеи такие интересные по поводу RLS и индексов? :)
RLS - это дополнительная "развертка" вглубь проверяемых типов данных в целях проверки "на вшивость" (т.е. на легитимность использования), помноженная на количество объектов с проверяемым типом данных в текущих данных, плюс их соединения со множеством всяких дополнительных таблиц (регистры свойств, разрешенией, доступа и т.д. - которые без RLS не задействуются, или используются крайне редко) - отсюда и существенные тормоза.
И чем больше RLS (даже без "несколько ролей") - тем все больше и больше будет обработка данных (для отчетов, открытия документов, выборки из регистров..)
Кроме того в запросе появляется возможность использования "Разрешенных"
В запросах ВСЕГДА есть возможность использовать РАЗРЕШЕННЫЕ. Только когда RLS не включен - эта инструкция пропускается, а когда включен - отрабатывает. Причем не так, как вы думаете.
И RLS - это не "позволяет не прописывать эти провреки везде (во всех формах)", а проверки доступа на уровне записей в БД. А приоверка в коде - это проверка на уровне исполнения кода (в ветку попало - проверилось, в ветку не попало - не проверилось).
(6) AlexO,
Про индексы: Если например мы делаем RLS по реквизиту документа "Организация" то по сути дела при запросе на уровне БД (запрос который сервер приложение отправит на сервер БД для получения данных) на таблицу документа наложится по полю "Организация" дополнительное условие (через соединения, и т.д. и т.п. но все равно условие). Как известно, результат отбора по условию с использованим индекса (в идеале покрывающего) сработает быстрее, чем без индекса. Отсюда ввывод если реквизит "Организация" будет проиндексирован доступные объекты по этой RLS-ке будут получитьася быстрее.
Про разрешенные: все правильно в запросах они всегда есть, но если мы используем RLS, то не надо в запрос для конкретного пользоватля добавлять каие-то сверх условия если нужно получить не все записи, а только доступные ему
(это и подразумевалось под фразой "Становится доступным" - иначе оно конечно есть, но пользы от него нет :) ). Система сама дополнит эти отборы по правам при приобразовании запроса 1С в запрос к БД.
Может конечно ошибаюсь, поправте.
ЗЫ. Может я вобще не правильно понимаю что такое RLS - я считаю что это дополнительныые условия кторые мы прописывам в ролях (в режиме конфигурирования, в нижней правой таблице) для доступа к отдельным записям таблиц на то или иное действие (чтение, просмотр, и т.п.)
Про индексы: Если например мы делаем RLS по реквизиту документа "Организация" то по сути дела при запросе на уровне БД (запрос который сервер приложение отправит на сервер БД для получения данных) на таблицу документа наложится по полю "Организация" дополнительное условие (через соединения, и т.д. и т.п. но все равно условие). Как известно, результат отбора по условию с использованим индекса (в идеале покрывающего) сработает быстрее, чем без индекса. Отсюда ввывод если реквизит "Организация" будет проиндексирован доступные объекты по этой RLS-ке будут получитьася быстрее.
Про разрешенные: все правильно в запросах они всегда есть, но если мы используем RLS, то не надо в запрос для конкретного пользоватля добавлять каие-то сверх условия если нужно получить не все записи, а только доступные ему
(это и подразумевалось под фразой "Становится доступным" - иначе оно конечно есть, но пользы от него нет :) ). Система сама дополнит эти отборы по правам при приобразовании запроса 1С в запрос к БД.
Может конечно ошибаюсь, поправте.
ЗЫ. Может я вобще не правильно понимаю что такое RLS - я считаю что это дополнительныые условия кторые мы прописывам в ролях (в режиме конфигурирования, в нижней правой таблице) для доступа к отдельным записям таблиц на то или иное действие (чтение, просмотр, и т.п.)
(20) Ягг,
Сам механизм RLS, как и реализация платформы, 1С не раскрывается.
Поэтому судить можно лишь по косвенным признакам.
А косвенные признаки как раз говорят о том, что в случае отработки RLS-запроса с сервера СУБД 1С-сервер получает ВСЕ запрошенные данные без разделения на "разрешенные" (собственно, тот факт, что такой инструкции нет в T-SQL, а естт в 1С, лишь подтверждает сказанное) и "не разрешенные" (а если еще и связанные таблицы были запрошены - то и все связанные таблицы целиком, без наложения отбора средствами СУБД, какой накладывается на первичные таблицы данных), и уже 1С-сервер посредством механизма RLS "отсеивает" нелегитимные записи.
Собственно, то, что RLS - детище целиком и полностью 1С, не имея никаких аналогов в СУБД SQL, является достаточным и окончательным доводом в данном вопросе.
С файловым вариантом работы, я думаю, тем более будет все понятно.
А что касается самих индексов - то никакой индексации таблиц (регистров, документов) в БД 1С нет и не было. Поделку в виде "индексации" измерений даже рассматривать не стоит - это фикция.
А к ключам и индексам СУБД SQL база 1С имеет весьма и весьма отдаленное отношение - его можно сравнить с землей, на которой стоит база 1С. И 1С не использует индексацию "земли"-СУБД НИКАК. То есть совсем. Если СУБД проиндексирует там чего-то у чебя, то и хорошо.
Если бы использовала - скорость работы была бы на два-три порядка выше.
Вот здесь точно не так. Если побольше повозитесь с RLS, то и сами найдете, почему.
Если не использовать РАЗРЕШЕННЫЕ, но наложить RLS, и он не разрешит какие-то записи для использования в запросе - 1С просто и тупо (как она делает во всех "сложных" для неё случаях) вылетит с ошибкой.
Поэтому РАЗРЕШЕННЫЕ в запросах, на поля которых могут быть наложены условия RLS, нужно указывать ОБЯЗАТЕЛЬНО, если используется или даже планируется использовать RLS.
И здесь целиком и полностью работает и обрабатывает все ТОЛЬКО сервер 1С, и никто другой.
никакого запроса с условиями RLS или "по правам" к БД (к БД которая на СУБД) не существует. Прав и условий RLS от 1С для сторонних СУБД (SQL etc) не существует. Все целиком и полностью происходит на сервере 1С.
... то по сути дела при запросе на уровне БД на таблицу документа наложится по полю "Организация" ... результат отбора по условию с использованим индекса (в идеале покрывающего) сработает быстрее, чем без индекса
Сам механизм RLS, как и реализация платформы, 1С не раскрывается.
Поэтому судить можно лишь по косвенным признакам.
А косвенные признаки как раз говорят о том, что в случае отработки RLS-запроса с сервера СУБД 1С-сервер получает ВСЕ запрошенные данные без разделения на "разрешенные" (собственно, тот факт, что такой инструкции нет в T-SQL, а естт в 1С, лишь подтверждает сказанное) и "не разрешенные" (а если еще и связанные таблицы были запрошены - то и все связанные таблицы целиком, без наложения отбора средствами СУБД, какой накладывается на первичные таблицы данных), и уже 1С-сервер посредством механизма RLS "отсеивает" нелегитимные записи.
Собственно, то, что RLS - детище целиком и полностью 1С, не имея никаких аналогов в СУБД SQL, является достаточным и окончательным доводом в данном вопросе.
С файловым вариантом работы, я думаю, тем более будет все понятно.
А что касается самих индексов - то никакой индексации таблиц (регистров, документов) в БД 1С нет и не было. Поделку в виде "индексации" измерений даже рассматривать не стоит - это фикция.
А к ключам и индексам СУБД SQL база 1С имеет весьма и весьма отдаленное отношение - его можно сравнить с землей, на которой стоит база 1С. И 1С не использует индексацию "земли"-СУБД НИКАК. То есть совсем. Если СУБД проиндексирует там чего-то у чебя, то и хорошо.
Если бы использовала - скорость работы была бы на два-три порядка выше.
то не надо в запрос для конкретного пользоватля добавлять каие-то сверх условия если нужно получить не все записи, а только доступные ему
Вот здесь точно не так. Если побольше повозитесь с RLS, то и сами найдете, почему.
Если не использовать РАЗРЕШЕННЫЕ, но наложить RLS, и он не разрешит какие-то записи для использования в запросе - 1С просто и тупо (как она делает во всех "сложных" для неё случаях) вылетит с ошибкой.
Поэтому РАЗРЕШЕННЫЕ в запросах, на поля которых могут быть наложены условия RLS, нужно указывать ОБЯЗАТЕЛЬНО, если используется или даже планируется использовать RLS.
И здесь целиком и полностью работает и обрабатывает все ТОЛЬКО сервер 1С, и никто другой.
Система сама дополнит эти отборы по правам при приобразовании запроса 1С в запрос к БД.
никакого запроса с условиями RLS или "по правам" к БД (к БД которая на СУБД) не существует. Прав и условий RLS от 1С для сторонних СУБД (SQL etc) не существует. Все целиком и полностью происходит на сервере 1С.
(21) AlexO, ух... ну еще раз :)
сначала про "дополнительные условия" - все справедливо, конечно нужно использовать РАЗРЕШЕННЫЕ (видимо я не корректно написал и меня не поняли :) ).
Про "страшный" секрет реализации RLS. С тех пор как появились SQL профайлеры туда таки можо заглянуть :)
Проведем эксперимент.
Итак, есть у нас справочник "Справочник1" у которого есть реквизит "Реквизит1". Делаем простой запрос в 1С
"Выбрать Ссылка из Справочники.Справочник1", даже так, добавим слово Разрешенные (у нас пока никаких ограниченйи нет - добавим просто для чистоты эксперимента, понятно что от этого РАЗРЕШЕННОГО ничего не изменится). Вообщем запрос 1С:
Выполняем запрос и смотрим профайлер. На сервер уходит:
Теперь заходим в конфигуратор, добавляем роль, ставим у этой роли на чтение "справочника1" доп условие:
т.е. тупо, не усложняем себе жизнь мы говорим что читаем только те элементы у которых "Реквизит1 = 1". Ставим эту роль основоной. Заходим в 1С и выполняем тот же самый запрос что и вначале. Смотрим в профайлер, как он ушел к БД.
Видим что запрос уже имеет вид:
Не вдаваясь в детали нас инетресуте "._Fld3 = CAST.." - это как раз и есть наше условие в RLS "Реквизит1 = 1".
Думаю, что если "_Fld3" (Реквизит1) будет проиндексировано то этот запрос в SQL отработает быстрее.
Отсюда и моя фраза про подходящие индексы :)
ЗЫ. Никакая система не будет нормально функционировать в случае если мы сначала из БД получаем "все" а потм отсеиваем ненужное. Это будет не жизнеспособная система (жуткие излишние затраты тарфика и прочее - вы слишком плохого мнения о реализации 1С :) ). Суть RLS иммено в наложение дополнительных условий на запрос к БД с целью сразу получить только подходящие данные. Я делаю такой вывод хотя бы из приведеного эксперимента (да и просто из здравого смысла).
К слову сказать в случае любой другой БД (не SQL) подход не меняется.
ЗЫЗЫ. Кстати, очень похоже что вы немного спутали реализацию RLS и "Управляемые блокировки данных", которые к RLS никакого отношения не имеют. Действительно "управляемые" целиком и польностью лежат на "плечах" сервера приложения 1С (иммено этот контроль не "проваливается" в БД).
ЗЫЗЫЗЫЗ :)
А поповоду
сначала про "дополнительные условия" - все справедливо, конечно нужно использовать РАЗРЕШЕННЫЕ (видимо я не корректно написал и меня не поняли :) ).
Про "страшный" секрет реализации RLS. С тех пор как появились SQL профайлеры туда таки можо заглянуть :)
Проведем эксперимент.
Итак, есть у нас справочник "Справочник1" у которого есть реквизит "Реквизит1". Делаем простой запрос в 1С
"Выбрать Ссылка из Справочники.Справочник1", даже так, добавим слово Разрешенные (у нас пока никаких ограниченйи нет - добавим просто для чистоты эксперимента, понятно что от этого РАЗРЕШЕННОГО ничего не изменится). Вообщем запрос 1С:
ВЫБРАТЬ РАЗРЕШЕННЫЕ
Справочник1.Ссылка
ИЗ
Справочник.Справочник1 КАК Справочник1Выполняем запрос и смотрим профайлер. На сервер уходит:
SELECT
_Reference1_Q_000_T_001._IDRRef AS f_1
FROM
_Reference1 _Reference1_Q_000_T_001 WITH(NOLOCK)Теперь заходим в конфигуратор, добавляем роль, ставим у этой роли на чтение "справочника1" доп условие:
Справочник1 ГДЕ Справочник1.Реквизит1 = 1Видим что запрос уже имеет вид:
exec sp_executesql N'SELECT
_Reference1_Q_000_T_001._IDRRef AS f_1
FROM
_Reference1 _Reference1_Q_000_T_001 WITH(NOLOCK)
WHERE
_Reference1_Q_000_T_001._Fld3 = CAST(@P1 AS NUMERIC(1,0))',N'@P1 numeric(1)',1Не вдаваясь в детали нас инетресуте "._Fld3 = CAST.." - это как раз и есть наше условие в RLS "Реквизит1 = 1".
Думаю, что если "_Fld3" (Реквизит1) будет проиндексировано то этот запрос в SQL отработает быстрее.
Отсюда и моя фраза про подходящие индексы :)
ЗЫ. Никакая система не будет нормально функционировать в случае если мы сначала из БД получаем "все" а потм отсеиваем ненужное. Это будет не жизнеспособная система (жуткие излишние затраты тарфика и прочее - вы слишком плохого мнения о реализации 1С :) ). Суть RLS иммено в наложение дополнительных условий на запрос к БД с целью сразу получить только подходящие данные. Я делаю такой вывод хотя бы из приведеного эксперимента (да и просто из здравого смысла).
К слову сказать в случае любой другой БД (не SQL) подход не меняется.
ЗЫЗЫ. Кстати, очень похоже что вы немного спутали реализацию RLS и "Управляемые блокировки данных", которые к RLS никакого отношения не имеют. Действительно "управляемые" целиком и польностью лежат на "плечах" сервера приложения 1С (иммено этот контроль не "проваливается" в БД).
ЗЫЗЫЗЫЗ :)
А поповоду
А что касается самих индексов - то никакой индексации таблиц (регистров, документов) в БД 1С нет и не было. Поделку в виде "индексации" измерений даже рассматривать не стоит - это фикция.
тут даже слов нет :) предпологаю, что я не правильно понял эту фразу :) Вы хоть предтавляете себе скорость работы базы данных без индексов? :) Из любопытсва можно посмотреть в книге "Радченко, М. Г., Хрусталева, Е. Ю. Архитектура и работа с данными "1С:Предприятия 8.2". Москва – 2011." про индексы в 1С. Хотя, еще раз скажу, все таки думаю что я не правильно понял эту фразу :)
(22) Ягг,
И где тут RLS? Вы привели всего лишь интрепретацию ПРЯМОГО запроса 1С-сервера к таблицам SQL.
именно так в большинстве случаев и работает 1С-сервер. Получает все, отсеивает ненужное и собирает в нужном ракурсе. А именно - когда идет запрос к связанным таблицам (соединения, разименования и прочее).
представляю. Это 1С. Которая в большинстве своем работает БЕЗ ИНДЕКСОВ. Про меншинство с "индексами" я уже писал выше.
То, что постоянно путают (кто - по незнанию, кто - намеренно) индексацию SQL-базы и отсутствие таковой в логической базе данных 1С - давно известно.
Индексами СУБД SQL пользуется сам SQL. Логикой хранения записей 1С пользуется 1С. В первом случае есть индексация, реляционные таблицы и прочие достижения развития СУБД.
Во-втором - отсутствие индексов, отсутствие реляционных таблиц, жалкие потуги на это в виде регистров, и прочие "достижения" 1С в области хранения и управления данными.
Связь-то какая между двумя логиками хранения и обработки БД?
Или вы путаете "индекс" логической ячейки хранения, который в принципе обеспечивет нахождение её среди других ячеек (в памяти, на дестком диске и т.д.), и индексацию ЗАПИСЕЙ (данных) в СУБД для быстрого отбора нужных записей.
В первом случае ничего делать не надо - все практически делается на аппаратном уровне, бери и пользуйся.
Во-втором - нужно разрабатывать серьезную СУБД, которая, в том числе и для индексации - требует и управление записью, анализатор данных, оптимизатор размещения и прочее, и прочее. Что есть в SQl, и отстутсвует в 1С (откуда и стоимость продукта соответствующая).
Сервер 1С делает запрос к SQL и получает массу "сырых" и зачастую даже не отобранных (или отобранных очень широко) данных.
Сколько там и чего - следите за нагрузкой на память при работе SQL сервера, и сравните, что получаете на выходе якобы "при запросе в базу". Если не понятно - переведите полученную таблицу в байты информации, и сравните с объемом памяти, который потребовался для обработки такого "небольшого" запроса от 1С-сервера в SQL-базе.
А уже всю ОСНОВНУЮ работу по отбору, сортировке, выборке, соединении таблиц и всяких прочих объединений выполняет 1С сервер.
Что тоже очень даже наглядно видно при расчете той же себестоимости на большом предприятии.
Полноценная индексация, поиск по ключам невозможен в 1С по одной простой причине: там нет реляционных полей, а есть ссылочные связи, перепутанные донельзя между собой. И, таким образом, 1С сама себя загнала в эту ловушку "ссылочности", дыры от которой остается "замазывать" только маркетингом и "теориями" индексации из 1с-овых книжек.
Вы хоть раз задумались, почему 1С упорно рекомендует разделять при мало-мальских нагрузках SQL и 1С сервер? Что было бы совершенно не нужно, если бы и хранение, и выборки, и обработка осуществлялись в единой среде и единым процессом.
И вообще, мне интересно посмотреть на 1с-ников, которые будут администрировать SQL-сервера и управлять распределением нагрузок с книжкой от 1С по базам данных.
А вот придумки выдумывать да сочинять там, где и так мутности выше крыше - она вполне подойдет, тут я не спорю совершенно :)
Собственно, каждое новое поколение 8-шников - каждый раз одни и те же грабли и самообман с цитатами из книжек главного обманщика :))
Думаю, что если "_Fld3" (Реквизит1) будет проиндексировано то этот запрос в SQL отработает быстрее.
И где тут RLS? Вы привели всего лишь интрепретацию ПРЯМОГО запроса 1С-сервера к таблицам SQL.
ЗЫ. Никакая система не будет нормально функционировать в случае если мы сначала из БД получаем "все" а потм отсеиваем ненужное.
именно так в большинстве случаев и работает 1С-сервер. Получает все, отсеивает ненужное и собирает в нужном ракурсе. А именно - когда идет запрос к связанным таблицам (соединения, разименования и прочее).
Вы хоть предтавляете себе скорость работы базы данных без индексов?
представляю. Это 1С. Которая в большинстве своем работает БЕЗ ИНДЕКСОВ. Про меншинство с "индексами" я уже писал выше.
То, что постоянно путают (кто - по незнанию, кто - намеренно) индексацию SQL-базы и отсутствие таковой в логической базе данных 1С - давно известно.
Индексами СУБД SQL пользуется сам SQL. Логикой хранения записей 1С пользуется 1С. В первом случае есть индексация, реляционные таблицы и прочие достижения развития СУБД.
Во-втором - отсутствие индексов, отсутствие реляционных таблиц, жалкие потуги на это в виде регистров, и прочие "достижения" 1С в области хранения и управления данными.
Связь-то какая между двумя логиками хранения и обработки БД?
Или вы путаете "индекс" логической ячейки хранения, который в принципе обеспечивет нахождение её среди других ячеек (в памяти, на дестком диске и т.д.), и индексацию ЗАПИСЕЙ (данных) в СУБД для быстрого отбора нужных записей.
В первом случае ничего делать не надо - все практически делается на аппаратном уровне, бери и пользуйся.
Во-втором - нужно разрабатывать серьезную СУБД, которая, в том числе и для индексации - требует и управление записью, анализатор данных, оптимизатор размещения и прочее, и прочее. Что есть в SQl, и отстутсвует в 1С (откуда и стоимость продукта соответствующая).
Сервер 1С делает запрос к SQL и получает массу "сырых" и зачастую даже не отобранных (или отобранных очень широко) данных.
Сколько там и чего - следите за нагрузкой на память при работе SQL сервера, и сравните, что получаете на выходе якобы "при запросе в базу". Если не понятно - переведите полученную таблицу в байты информации, и сравните с объемом памяти, который потребовался для обработки такого "небольшого" запроса от 1С-сервера в SQL-базе.
А уже всю ОСНОВНУЮ работу по отбору, сортировке, выборке, соединении таблиц и всяких прочих объединений выполняет 1С сервер.
Что тоже очень даже наглядно видно при расчете той же себестоимости на большом предприятии.
Полноценная индексация, поиск по ключам невозможен в 1С по одной простой причине: там нет реляционных полей, а есть ссылочные связи, перепутанные донельзя между собой. И, таким образом, 1С сама себя загнала в эту ловушку "ссылочности", дыры от которой остается "замазывать" только маркетингом и "теориями" индексации из 1с-овых книжек.
Вы хоть раз задумались, почему 1С упорно рекомендует разделять при мало-мальских нагрузках SQL и 1С сервер? Что было бы совершенно не нужно, если бы и хранение, и выборки, и обработка осуществлялись в единой среде и единым процессом.
И вообще, мне интересно посмотреть на 1с-ников, которые будут администрировать SQL-сервера и управлять распределением нагрузок с книжкой от 1С по базам данных.
А вот придумки выдумывать да сочинять там, где и так мутности выше крыше - она вполне подойдет, тут я не спорю совершенно :)
Собственно, каждое новое поколение 8-шников - каждый раз одни и те же грабли и самообман с цитатами из книжек главного обманщика :))
(26) AlexO, вы меня извините, доводы у меня закончились :)
Может ошибаюсь, но мне кажется у вас немного неправильные прадставление о воимоотношениях между сервером 1С и сервером базы данных (у них соверршено разные назначения), да и об архитектуре данных (посмотрите в книге по этому вопросу).
Боюсь, что такие высказывания как "логическую базу 1С... отсутствие индексов... отсутствие реляционных таблиц" заставит нас "откатьться" далеко назад и для начала разобраться что вы под этим понимаете :)
Те ошибки которые приведены (тормоза и все такое), следствие не правильной орагнизации данных (в том числе и на очень эмоциональном постулате отсвувия индексов - конечно, если их не использовать все будет тормозить :) ). А то что "Сервер 1С получает сырые данные" - так это опять таки вина разработчика, не правильно организовавшего запрос.
Честно говоря я вобще не понимаю о каких таблицах 1С (кроме тех что в БД) идет речь. Много эмоций :)
ЗЫ. Мне просто интрересно, а какие таблицы (если не реляционные) используются в базе данных 1С? :)
Может ошибаюсь, но мне кажется у вас немного неправильные прадставление о воимоотношениях между сервером 1С и сервером базы данных (у них соверршено разные назначения), да и об архитектуре данных (посмотрите в книге по этому вопросу).
Боюсь, что такие высказывания как "логическую базу 1С... отсутствие индексов... отсутствие реляционных таблиц" заставит нас "откатьться" далеко назад и для начала разобраться что вы под этим понимаете :)
Те ошибки которые приведены (тормоза и все такое), следствие не правильной орагнизации данных (в том числе и на очень эмоциональном постулате отсвувия индексов - конечно, если их не использовать все будет тормозить :) ). А то что "Сервер 1С получает сырые данные" - так это опять таки вина разработчика, не правильно организовавшего запрос.
Честно говоря я вобще не понимаю о каких таблицах 1С (кроме тех что в БД) идет речь. Много эмоций :)
ЗЫ. Мне просто интрересно, а какие таблицы (если не реляционные) используются в базе данных 1С? :)
(27) Ягг,
Т.е. вы думаете, что таблицы (регистры там, списки документов и прочее) - это все таблицы SQL в том же виде, как вы их видите?
(27) Ягг,
Реляционная таблицы (база) и просто таблицы - это совершенно разные вещи.
Тут уже надо спросить вас: а что вы знаете про реляционные СУБД?
Что за правило Кодда такое - "Правило гарантированного доступа" (как раз по теме выбранной вами индексации и для чего она нужна в первую очередь)? И как оно соответствует структуре хранения у 1С?
И всем остальным требованиям Реляционной Базы Данных.
А не той чуши, которую порют 1с-овцы и прочие "студенты" последнего времени :)
Честно говоря я вобще не понимаю о каких таблицах 1С (кроме тех что в БД) идет речь.
Т.е. вы думаете, что таблицы (регистры там, списки документов и прочее) - это все таблицы SQL в том же виде, как вы их видите?
(27) Ягг,
ЗЫ. Мне просто интрересно, а какие таблицы (если не реляционные) используются в базе данных 1С?
Реляционная таблицы (база) и просто таблицы - это совершенно разные вещи.
Тут уже надо спросить вас: а что вы знаете про реляционные СУБД?
Что за правило Кодда такое - "Правило гарантированного доступа" (как раз по теме выбранной вами индексации и для чего она нужна в первую очередь)? И как оно соответствует структуре хранения у 1С?
И всем остальным требованиям Реляционной Базы Данных.
А не той чуши, которую порют 1с-овцы и прочие "студенты" последнего времени :)
(28) AlexO, нет, я не думаю что регистры, справочники и прочее это таблицы SQL в том виде как я их вижу. Более того, я даже не думаю что это вообще таблицы :) Это "Объекты метаданных". Каждому из этих объектов соовтествует энное количество реаляционных (причем очень сомневаюсь что может быть какого-то другого типа - не встречал) таблиц в базе данных (к слову, понятие объект метаданных не ограничиватся совокупоностью таблиц).
Честно скажу, правила Кодда я тока что посмотрел (в википедии), гарантированость доступа звучит так:
и не совсем понимаю чем 1С его нарушает? Есть кластерные индексы (первичные ключи), есть уникальность имен таблиц и колонок.
Знаете, я предлагаю не ругаться (и выяснять кто хитрее :))
Пусть каждый останется при своем мнении (оно ведь взялось не из воздуха и имеет некое "материальное" основнаие). В конце концов у каждого свои базы, свои представляния о правилах их разработки и если заказчики и пользователи довольны - то и хорошо :) Такие диспуты гораздо удобнее вести очно, а тут мы только забъем ветку "голимой теорией" :)
Честно скажу, правила Кодда я тока что посмотрел (в википедии), гарантированость доступа звучит так:
Доступ к данным должен быть свободен от двусмысленности. К каждому элементу данных должен быть
гарантирован доступ с помощью комбинации имени таблицы, первичного ключа строки
и имени столбца.
и не совсем понимаю чем 1С его нарушает? Есть кластерные индексы (первичные ключи), есть уникальность имен таблиц и колонок.
Знаете, я предлагаю не ругаться (и выяснять кто хитрее :))
Пусть каждый останется при своем мнении (оно ведь взялось не из воздуха и имеет некое "материальное" основнаие). В конце концов у каждого свои базы, свои представляния о правилах их разработки и если заказчики и пользователи довольны - то и хорошо :) Такие диспуты гораздо удобнее вести очно, а тут мы только забъем ветку "голимой теорией" :)
(29) Ягг,
В реционных базах нет понятия "объекты".
При работе в SQL и прочих СУБД - соответствует.
Только "объект" и "набор реляционных таблиц" - не одно и то же.
Первые - "элемент" базы 1С, вторые - элемент базы SQL.
Вы работаете с объектами, 1С-сервер интерпретирует запрос из ОБЪЕКТОВ к реляционным таблицам SQL, получает ИСХОДНЫЙ набор данных, интерпретирует их обратно в логику базы 1С, обрабатывает в ЛОГИКЕ БАЗЫ 1С, и выводит вам результат.
Остальная промежуточная детализация этого процесса - мной подробно описана выше.
При такой неповоротливой схеме 1С умудрились еще и сильно ограничить объем пакета одновременно обрабатываемых данных в 1С-сервере.
и где же сам доступ с помощью комбинации поля-ключа, колонки и столбца? Напомните-ка, чем в первую очередь характеризуется так называемый "объект" в 1С? :)
это не теория, а чистая практика работы на множестве УПП-шных баз, разбора материала (заочно - с тем же Гилевым, главным "специалистом" по производительности и масштабируемости), куча проблем при больших загрузках и невозможность их решения кроме двух путей:
1) увеличивать многократно вычислительные мощности (и повторять этот процесс раз в 2-3 года).
2) "скармливать" 1С-серверу меньшие куски данных для обработки, дабы он "не подавился".
Есть и третий вариант, тоже не редко предлагаемый 1С: отказаться от таких вычислений и детализации в производстве, и страдать херней в рамках "методик" 1С :)
Это "Объекты метаданных"
В реционных базах нет понятия "объекты".
Каждому из этих объектов соовтествует энное количество реаляционных таблиц в базе данных
При работе в SQL и прочих СУБД - соответствует.
Только "объект" и "набор реляционных таблиц" - не одно и то же.
Первые - "элемент" базы 1С, вторые - элемент базы SQL.
Вы работаете с объектами, 1С-сервер интерпретирует запрос из ОБЪЕКТОВ к реляционным таблицам SQL, получает ИСХОДНЫЙ набор данных, интерпретирует их обратно в логику базы 1С, обрабатывает в ЛОГИКЕ БАЗЫ 1С, и выводит вам результат.
Остальная промежуточная детализация этого процесса - мной подробно описана выше.
При такой неповоротливой схеме 1С умудрились еще и сильно ограничить объем пакета одновременно обрабатываемых данных в 1С-сервере.
Есть кластерные индексы (первичные ключи), есть уникальность имен таблиц и колонок.
и где же сам доступ с помощью комбинации поля-ключа, колонки и столбца? Напомните-ка, чем в первую очередь характеризуется так называемый "объект" в 1С? :)
"голимой теорией"
это не теория, а чистая практика работы на множестве УПП-шных баз, разбора материала (заочно - с тем же Гилевым, главным "специалистом" по производительности и масштабируемости), куча проблем при больших загрузках и невозможность их решения кроме двух путей:
1) увеличивать многократно вычислительные мощности (и повторять этот процесс раз в 2-3 года).
2) "скармливать" 1С-серверу меньшие куски данных для обработки, дабы он "не подавился".
Есть и третий вариант, тоже не редко предлагаемый 1С: отказаться от таких вычислений и детализации в производстве, и страдать херней в рамках "методик" 1С :)
(30) AlexO, ну давайте еще немного покидаемся :)
Конечно нет. Но это объекты НЕ базы, а конфигурации 1С (программной части 1С). Уточню что, под "конфигурацией" понимается именно прогрммная часть информмационной базы (то, что програмируется в конфигураторе).
Что объекты метаданных это не только таблицы, как они интерпритируются в SQL и т.д. - так и я об этом говорю (вроде бы расхождения в представлении нет - зачем повторять не понятно).
Доступ через "комбинации поля-ключа", как я понимаю (поправте) это значит по первичному ключу однозначно идентифицируется запись в таблице, и у этой записи имеется одназначно идентифицируемое поле значение из которого нужно взять. У всех таблиц 1С есть первиччные ключи, имена всех столбцов в пределах таблицы уникальны. В чем нарушение правила?
Про "чем характеризуется объект в 1С" - я вообще не понял (подозреваю что провокация :) )
Ну и сожалею что была "куча проблем...". По этому поводу скажу что 1С не панацея а лишь одна из возможностей (со своими плюсами и минусами). Если она не отвечает требованиям учета предприятия не надо мучитить попу, а выбирайте другой продукт.
Но реально, тема скатывается в спам. Оно нам надо? :)
В реционных базах нет понятия "объекты".
Конечно нет. Но это объекты НЕ базы, а конфигурации 1С (программной части 1С). Уточню что, под "конфигурацией" понимается именно прогрммная часть информмационной базы (то, что програмируется в конфигураторе).
Что объекты метаданных это не только таблицы, как они интерпритируются в SQL и т.д. - так и я об этом говорю (вроде бы расхождения в представлении нет - зачем повторять не понятно).
Доступ через "комбинации поля-ключа", как я понимаю (поправте) это значит по первичному ключу однозначно идентифицируется запись в таблице, и у этой записи имеется одназначно идентифицируемое поле значение из которого нужно взять. У всех таблиц 1С есть первиччные ключи, имена всех столбцов в пределах таблицы уникальны. В чем нарушение правила?
Про "чем характеризуется объект в 1С" - я вообще не понял (подозреваю что провокация :) )
Ну и сожалею что была "куча проблем...". По этому поводу скажу что 1С не панацея а лишь одна из возможностей (со своими плюсами и минусами). Если она не отвечает требованиям учета предприятия не надо мучитить попу, а выбирайте другой продукт.
Но реально, тема скатывается в спам. Оно нам надо? :)
(31) Ягг,
Реляционная модель же - это только таблицы и связи между ними.
по какому ключу вы "однозначно" идентифицируете объект "Документ"? :)
Подобие реляционной модели хранения данных было в 1С7.7 (и то только в SQL-вариантах), что позволяло писать прямые запросы к базе 7.7, и отсутствие чего же не позволяет их писать к базе 8.х.
Тут где-то в соседней теме очередной "студент" тоже порывался писать прямые запросы в восьмерке, но кроме таких же мантр "... можно писать прямые запросы..." ничего боле не привел в доказательство :)
да, это верно - ССЫЛКА на объект - это огромная провокация и мистификация от 1С. Вы вон до сих пор не то чтобы разобрались в вопросе, но и даже не замечаете её в упор :)
Хотя это альфа (и ... все, окончания пока нет и не видно) и основание всей логики хранения и обработки данных в 1С.
как у вас все просто :)
Как на презентациях 1с.
Значит, заплатили денег, внедрили, поработали год, еще заплатили, еще - и опять доработали, а потом - "а, не подходит, давайте менять все" :)
Что объекты метаданных это не только таблицы
Реляционная модель же - это только таблицы и связи между ними.
это значит по первичному ключу однозначно идентифицируется запись в таблице
по какому ключу вы "однозначно" идентифицируете объект "Документ"? :)
Подобие реляционной модели хранения данных было в 1С7.7 (и то только в SQL-вариантах), что позволяло писать прямые запросы к базе 7.7, и отсутствие чего же не позволяет их писать к базе 8.х.
Тут где-то в соседней теме очередной "студент" тоже порывался писать прямые запросы в восьмерке, но кроме таких же мантр "... можно писать прямые запросы..." ничего боле не привел в доказательство :)
я вообще не понял (подозреваю что провокация)
да, это верно - ССЫЛКА на объект - это огромная провокация и мистификация от 1С. Вы вон до сих пор не то чтобы разобрались в вопросе, но и даже не замечаете её в упор :)
Хотя это альфа (и ... все, окончания пока нет и не видно) и основание всей логики хранения и обработки данных в 1С.
Если она не отвечает требованиям учета предприятия
как у вас все просто :)
Как на презентациях 1с.
Значит, заплатили денег, внедрили, поработали год, еще заплатили, еще - и опять доработали, а потом - "а, не подходит, давайте менять все" :)
(27) Ягг,
они бы у вас раньше закончились, что дало бы вам дополнительное время для изучения вопроса, если бы вы не читали 1с-овых книжек :)
В толстой умной книжке "Профессиональное программирование в 1С" было конкретно указано на многие слабые моменты реализации сервера 1С. Честно, прямо и открыто.
В новых книжках-малышках, по-моему, этот вопрос "случайно" обойден.
вы меня извините, доводы у меня закончились
они бы у вас раньше закончились, что дало бы вам дополнительное время для изучения вопроса, если бы вы не читали 1с-овых книжек :)
В толстой умной книжке "Профессиональное программирование в 1С" было конкретно указано на многие слабые моменты реализации сервера 1С. Честно, прямо и открыто.
В новых книжках-малышках, по-моему, этот вопрос "случайно" обойден.
(26) AlexO,
"как много есть на свете, друг Гораций..."(с)
Честно говоря никогда всерьез не задумывался над тем как 1С балансирует нагрузку между сервером SQL и 1С, как-то предполагал, что это обычная клиент-серверная система.
Я правильно понял из ваших постов, что сервер 1С использует возможности SQL сервера только для хранения данных, а всю обработку данных проводит своими средствами?
"как много есть на свете, друг Гораций..."(с)
Честно говоря никогда всерьез не задумывался над тем как 1С балансирует нагрузку между сервером SQL и 1С, как-то предполагал, что это обычная клиент-серверная система.
Я правильно понял из ваших постов, что сервер 1С использует возможности SQL сервера только для хранения данных, а всю обработку данных проводит своими средствами?
(51) Mistrall, конечно, вопрос задан не мне, (и вобще я выпил йаду), но все таки выскажу свои извращенные мысли.
Сервер баз данных (к которым относится SQL-сервер) изначално предназначен только для хранения (быстрого предоставления) данных (это его основная цель). Команды Insert, Update и прочее - все это думается, следует рассматривать имено как механизмы хранения (ввода, редактирования) данных.
Вся обработка данных (програмная логика) заключена в серевре приложения. Сервер приложения получает от сервера БД данные (при этом страрется получить сразу минимально необходимую информацию), "обрабоатывает" (принимает решение что нужно изменить, дописать и удалить) и отправляет на сервер БД соотвествующие запросы (причем Insetr, Update - это тоже запросы) для изменения данных или чего-то там еще. Сервер БД эти запросы отрабатывает. И цель добиться что бы он (сервер БД) отработал эти запросы максимально быстро (для этого есть специальные подходы - в том числе и эти несчатсные индексы из-за которых столько копий поломано).
В этом собсвено и суть трехуровневой архитектуры (клиент - сервер приложения - сервре баз данных).
ЗЫ. Это не я придумал - по этому поводу есть много литературы, и все это подтверждается просто эксприментами с 1С. Это не философия - тут все проверяется эмперически :)
Сервер баз данных (к которым относится SQL-сервер) изначално предназначен только для хранения (быстрого предоставления) данных (это его основная цель). Команды Insert, Update и прочее - все это думается, следует рассматривать имено как механизмы хранения (ввода, редактирования) данных.
Вся обработка данных (програмная логика) заключена в серевре приложения. Сервер приложения получает от сервера БД данные (при этом страрется получить сразу минимально необходимую информацию), "обрабоатывает" (принимает решение что нужно изменить, дописать и удалить) и отправляет на сервер БД соотвествующие запросы (причем Insetr, Update - это тоже запросы) для изменения данных или чего-то там еще. Сервер БД эти запросы отрабатывает. И цель добиться что бы он (сервер БД) отработал эти запросы максимально быстро (для этого есть специальные подходы - в том числе и эти несчатсные индексы из-за которых столько копий поломано).
В этом собсвено и суть трехуровневой архитектуры (клиент - сервер приложения - сервре баз данных).
ЗЫ. Это не я придумал - по этому поводу есть много литературы, и все это подтверждается просто эксприментами с 1С. Это не философия - тут все проверяется эмперически :)
(52) Ягг,
Не Insert-ом единым... Триггеры, stored proc - я бы не стал рассматривать SQL сервер (в общем случае) только как хранилище. Многое зависит от реализации и именно это в отношении к 1С меня заинтересовало.
Команды Insert, Update и прочее - все это думается, следует рассматривать имено как механизмы хранения (ввода, редактирования) данных.
Не Insert-ом единым... Триггеры, stored proc - я бы не стал рассматривать SQL сервер (в общем случае) только как хранилище. Многое зависит от реализации и именно это в отношении к 1С меня заинтересовало.
(51) Mistrall,
практически, да.
Вся затея с внешними СУБД на 1С - это хоть как-то обеспечить приемлемую сетевую работу множества пользователей.
Все.
Широчайшие возможности SQL как СУБД проигнорированы и не используются.
То, что там в статейках пишет 1С, а потом повторяют студенты - ну надо же как-то инфу хранить и потом кое-как найти.
На этом функции SQL заканчиваются.
1С не использует индексацию SQL для выполнения запросов, если они не вида "select * from TABL where Field = ...", а индексация реквизитов в 1С - это не индексация данных в SQL. Работает криво, и больше тормозит, чем убыстряет.
что сервер 1С использует возможности SQL сервера только для хранения данных
практически, да.
Вся затея с внешними СУБД на 1С - это хоть как-то обеспечить приемлемую сетевую работу множества пользователей.
Все.
Широчайшие возможности SQL как СУБД проигнорированы и не используются.
То, что там в статейках пишет 1С, а потом повторяют студенты - ну надо же как-то инфу хранить и потом кое-как найти.
На этом функции SQL заканчиваются.
1С не использует индексацию SQL для выполнения запросов, если они не вида "select * from TABL where Field = ...", а индексация реквизитов в 1С - это не индексация данных в SQL. Работает криво, и больше тормозит, чем убыстряет.
(61) AlexO,
Блин, даже не верится как-то... Нет, я не оспариваю ваше заявление, мне просто поверить в это сложно.
А зачем тогда в объектах метаданных даны возможности индексации? По ним вроде даже индексы в БД создаются.
С другой стороны стало понятно зачем почти каждый запрос 1С громоздит гору временных таблиц...
1С не использует индексацию SQL для выполнения запросов, если они не вида "select * from TABL where Field = ...", а индексация реквизитов в 1С - это не индексация данных в SQL.
Блин, даже не верится как-то... Нет, я не оспариваю ваше заявление, мне просто поверить в это сложно.
А зачем тогда в объектах метаданных даны возможности индексации? По ним вроде даже индексы в БД создаются.
С другой стороны стало понятно зачем почти каждый запрос 1С громоздит гору временных таблиц...
(62) Mistrall,
Все таки попытаюсь спасти душу :)
Понимает, принимая таки радикальные утверждения (см. все что выше написал AlexO – ни в койм случае не осуждаю его мнение – его право) на веру вы рискуете своим программистским будущем (во как :) ) по крайней мере касательно 1С (да и вообще, "святая вера" - слабая позиция). Считая, что эти механизмы не работают вы не будете их использовать (Боги помогают только тем, кто в них верит). Как следствие ваши базы будут медленно работать. Крупные заказчики (причем именно крупные) будут от вас отказываться. Вам останется только сидеть и как мантру повторять "все плохо работает, все дураки" :)
Не верьте никому (и мне в том числе :) ). Слава богу, программирование наука техническая а не гуманитарная. Тут все проверяется опытным путем (бекапируйте сначала конечно). Почитайте теорию баз данных (не 1С, хотя бы официальную документацию по SQL). Посмотрите, как меняются таблицы (их индексы) когда вы ставите ту или иную галочку в конфигураторе 1С. Посмотрите планы выполнения запросов. Сделайте замеры производительности и т.д. и т.п. Это все не сложно и достаточно наглядно (по крайней мере в SQL, да и в ОRACLе при желании можно разобраться).
И потом уже делайте выводы.
ЗЫ. Этот тот случай, когда никому не надо верить – все врут – только опыт :) Но дело конечно ваше :)
Все таки попытаюсь спасти душу :)
Понимает, принимая таки радикальные утверждения (см. все что выше написал AlexO – ни в койм случае не осуждаю его мнение – его право) на веру вы рискуете своим программистским будущем (во как :) ) по крайней мере касательно 1С (да и вообще, "святая вера" - слабая позиция). Считая, что эти механизмы не работают вы не будете их использовать (Боги помогают только тем, кто в них верит). Как следствие ваши базы будут медленно работать. Крупные заказчики (причем именно крупные) будут от вас отказываться. Вам останется только сидеть и как мантру повторять "все плохо работает, все дураки" :)
Не верьте никому (и мне в том числе :) ). Слава богу, программирование наука техническая а не гуманитарная. Тут все проверяется опытным путем (бекапируйте сначала конечно). Почитайте теорию баз данных (не 1С, хотя бы официальную документацию по SQL). Посмотрите, как меняются таблицы (их индексы) когда вы ставите ту или иную галочку в конфигураторе 1С. Посмотрите планы выполнения запросов. Сделайте замеры производительности и т.д. и т.п. Это все не сложно и достаточно наглядно (по крайней мере в SQL, да и в ОRACLе при желании можно разобраться).
И потом уже делайте выводы.
ЗЫ. Этот тот случай, когда никому не надо верить – все врут – только опыт :) Но дело конечно ваше :)
(63) Ягг,
Документация и принципы работы SQL отношения к 1с базам не имеют.
Также, как и подключаясь к инету посмотреть погоду, вы не изучаете принципы построения сетей и функционирования сетевого оборудования.
Да, вы можете можете для более быстрого доступа (оптимизации получения данных) выбрать другого провайдера, подключаться к другому серверу, отключить вывод картинок в браузере и т.д. Но можете этого и не деалть, т.к. кардинально ничего не изменится: другой провайдер даст инет все по тем же ТфОП, другой сервер может и не ответить совсем, а отключение картинок и совсем уж может привести к невозможности узнать погоду.
а Вы много галочек знаете в 1с по оптимизации БД? :))
да еще и в конфигураторе....
хотя бы официальную документацию по SQL
Документация и принципы работы SQL отношения к 1с базам не имеют.
Также, как и подключаясь к инету посмотреть погоду, вы не изучаете принципы построения сетей и функционирования сетевого оборудования.
Да, вы можете можете для более быстрого доступа (оптимизации получения данных) выбрать другого провайдера, подключаться к другому серверу, отключить вывод картинок в браузере и т.д. Но можете этого и не деалть, т.к. кардинально ничего не изменится: другой провайдер даст инет все по тем же ТфОП, другой сервер может и не ответить совсем, а отключение картинок и совсем уж может привести к невозможности узнать погоду.
как меняются таблицы (их индексы) когда вы ставите ту или иную галочку в конфигураторе 1С.
а Вы много галочек знаете в 1с по оптимизации БД? :))
да еще и в конфигураторе....
(62) Mistrall,
это очередная провалившаяся попытка "мы знаем, как лучше" сделать оптимизацию "по-своему".
Да, индексы создаются. Но это индексы 1с, которые и обрабатывает сервер 1с, и то после того, как их получит.
Ни одному студенту-умнику дажек в голову не пришло рассуждение - а почему, собственно, если индексация данных это встроенный типовой механизм БД, то его надо ОБЯЗАТЕЛЬНО включать для реквизитов, а иначе ничего и не индексируется?
Вот конкретные примеры по справочникам, которые показывают разницу в индексации:
Индекс "Наименование + Ссылка" - обеспечивается средствами SQL, т.к. это ключи нормализованной таблицы БД. Соответственно, для поиска по БД задействован механизм поиска по индексам SQL, т.к. иного и быть не может - 1с не может вмешиваться в поиск на уровне СУБД SQL.
Но, почему-то, это становится "достижением" и "индексацией" 1с, хотя все "достижение" - это использование для хранения СУБД SQL.
А как отходим от поиска по нормализованной таблице - тут и возникают те самые знаменитые "индексируемые" тормоза.
Индекс "Реквизит + Наименование + Ссылка" - т.к. реквизит - это по большому счету, ссылочный тип, то по нему индексации SQL нет, и возможен другой, единственный вариант индексации - при вкл "Индексировать" (в доп поле для реквизита пишется уже 1с-овый "индекс") в этом реквизите возникает некая совместная индексация SQL+1С сервер, когда сервер получает проиндексированные данные основной таблицы "Наименование + Ссылка" плюс целиковые ссылочные таблицы по реквизиту, и уже сам ищет по своим индексам там среди данных реквизита.
Для реквизита примитивного же типа - да, в конечном итоге тоже отработает индексация SQL по нормализованнорй таблице (достаточно вкл "Индексировать" для этого реквизита в 1с): т.е. будет создан доп ключ "индекс" в таблице, который сразу даст данные. Но сколько таких реквизитов, учавствующих в поиске?
Это и есть настоящая "индексация" от 1с.
Соответственно, для всех ссылочных типов данных так называемая "индексация" крайне не рекомендуется. И, как следствие, чем больше и глубже ссылочность, тем тормознее и глюкавее такая "индексация".
затем, что для 1с-сервера вытаскиваются все нужные и ненужные ссылочные данные.
(63) Ягг,
механизмы индексации работает только в примитивных типах, когда возможно использование индекса SQL. Но нормализованных таблиц данных в базе 1с практически нет. Как правило, это лишь справочники с реквизитами только ПРИМИТИВНЫХ типов данных (т.е. одни числа, строки, булево). Много ли таких, да еще чтоб и элементов там было немеряно?
Боюсь, что у ваших круных заказчиков таких задач тоже не найдется. Так что будьте спокойны за Mistrall и его крупных заказчиков - решения этого вопроса в рамках 1с не существувет.
Как раз заказчику лучше не говорить про какую-то там индексацию в 1с, пусть сразу готовится к ж. - потому как работать она все равно не будет, а спрашивать "что же при вкл индексации нифига не летает?!" будут как раз с него, а не с 1с. И тут уж цитатками из статеек и книжек 1с не прикроешься... :)
А зачем тогда в объектах метаданных даны возможности индексации?
это очередная провалившаяся попытка "мы знаем, как лучше" сделать оптимизацию "по-своему".
Да, индексы создаются. Но это индексы 1с, которые и обрабатывает сервер 1с, и то после того, как их получит.
Ни одному студенту-умнику дажек в голову не пришло рассуждение - а почему, собственно, если индексация данных это встроенный типовой механизм БД, то его надо ОБЯЗАТЕЛЬНО включать для реквизитов, а иначе ничего и не индексируется?
Вот конкретные примеры по справочникам, которые показывают разницу в индексации:
Индекс "Наименование + Ссылка" - обеспечивается средствами SQL, т.к. это ключи нормализованной таблицы БД. Соответственно, для поиска по БД задействован механизм поиска по индексам SQL, т.к. иного и быть не может - 1с не может вмешиваться в поиск на уровне СУБД SQL.
Но, почему-то, это становится "достижением" и "индексацией" 1с, хотя все "достижение" - это использование для хранения СУБД SQL.
А как отходим от поиска по нормализованной таблице - тут и возникают те самые знаменитые "индексируемые" тормоза.
Индекс "Реквизит + Наименование + Ссылка" - т.к. реквизит - это по большому счету, ссылочный тип, то по нему индексации SQL нет, и возможен другой, единственный вариант индексации - при вкл "Индексировать" (в доп поле для реквизита пишется уже 1с-овый "индекс") в этом реквизите возникает некая совместная индексация SQL+1С сервер, когда сервер получает проиндексированные данные основной таблицы "Наименование + Ссылка" плюс целиковые ссылочные таблицы по реквизиту, и уже сам ищет по своим индексам там среди данных реквизита.
Для реквизита примитивного же типа - да, в конечном итоге тоже отработает индексация SQL по нормализованнорй таблице (достаточно вкл "Индексировать" для этого реквизита в 1с): т.е. будет создан доп ключ "индекс" в таблице, который сразу даст данные. Но сколько таких реквизитов, учавствующих в поиске?
Это и есть настоящая "индексация" от 1с.
Соответственно, для всех ссылочных типов данных так называемая "индексация" крайне не рекомендуется. И, как следствие, чем больше и глубже ссылочность, тем тормознее и глюкавее такая "индексация".
зачем почти каждый запрос 1С громоздит гору временных таблиц.
затем, что для 1с-сервера вытаскиваются все нужные и ненужные ссылочные данные.
(63) Ягг,
что эти механизмы не работают
механизмы индексации работает только в примитивных типах, когда возможно использование индекса SQL. Но нормализованных таблиц данных в базе 1с практически нет. Как правило, это лишь справочники с реквизитами только ПРИМИТИВНЫХ типов данных (т.е. одни числа, строки, булево). Много ли таких, да еще чтоб и элементов там было немеряно?
Боюсь, что у ваших круных заказчиков таких задач тоже не найдется. Так что будьте спокойны за Mistrall и его крупных заказчиков - решения этого вопроса в рамках 1с не существувет.
Как раз заказчику лучше не говорить про какую-то там индексацию в 1с, пусть сразу готовится к ж. - потому как работать она все равно не будет, а спрашивать "что же при вкл индексации нифига не летает?!" будут как раз с него, а не с 1с. И тут уж цитатками из статеек и книжек 1с не прикроешься... :)
(51) Mistrall,
добавлю еще, что SQL поставляет только "сырые" данные, и не преобразует и не обрабаотывает их "по объектам" - весь остальной разбор и обработку "объектов" делает 1С.
Я правильно понял из ваших постов, что сервер 1С использует возможности SQL сервера только для хранения данных, а всю обработку данных проводит своими средствами?
добавлю еще, что SQL поставляет только "сырые" данные, и не преобразует и не обрабаотывает их "по объектам" - весь остальной разбор и обработку "объектов" делает 1С.
(21)
Вы видимо не в курсе как работает 1С и взаимодействует с SQL.
Предлагаю ознакомиться со статьями:
А также половить запросы в профайлере и посмотреть планы выполнения таких запросов.
1С активно использует индексацию средствами СУБД.
Главное неудобство, что разработчик не может непосредственно управлять индексами таблиц SQL. Индексы строит 1С исходя из правил в первой статье и только по ним. "Если СУБД проиндексирует там чего-то у чебя, то и хорошо" - ничего общего с реальностью нет.
Если на практике встречаются тормозящие запросы, предлагаю ознакомиться со второй статьей. Из практики могу сказать, что изучение планов запросов, правильная индексация и использование временных таблиц позволяет получить ускорение на 1-2 порядка.
ЗЫ: все вышесказанное относится к 8.1/8.2.
7.7 - работает с СКЛ просто ужасно - вот она зачастую кидает выборку в ДБФ и там лопатит полным перебором...
А к ключам и индексам СУБД SQL база 1С имеет весьма и весьма отдаленное отношение - его можно сравнить с землей, на которой стоит база 1С. И 1С не использует индексацию "земли"-СУБД НИКАК. То есть совсем. Если СУБД проиндексирует там чего-то у чебя, то и хорошо.
Если бы использовала - скорость работы была бы на два-три порядка выше.
Если бы использовала - скорость работы была бы на два-три порядка выше.
Вы видимо не в курсе как работает 1С и взаимодействует с SQL.
Предлагаю ознакомиться со статьями:
А также половить запросы в профайлере и посмотреть планы выполнения таких запросов.
1С активно использует индексацию средствами СУБД.
Главное неудобство, что разработчик не может непосредственно управлять индексами таблиц SQL. Индексы строит 1С исходя из правил в первой статье и только по ним. "Если СУБД проиндексирует там чего-то у чебя, то и хорошо" - ничего общего с реальностью нет.
Если на практике встречаются тормозящие запросы, предлагаю ознакомиться со второй статьей. Из практики могу сказать, что изучение планов запросов, правильная индексация и использование временных таблиц позволяет получить ускорение на 1-2 порядка.
ЗЫ: все вышесказанное относится к 8.1/8.2.
7.7 - работает с СКЛ просто ужасно - вот она зачастую кидает выборку в ДБФ и там лопатит полным перебором...
(46) GreyJoJo,
слушайте, я уже устал с вами, студентами, бороться - или учите, что такое индексация, реляционная модель, ключи, или читайте и дальше агитки от 1С.
Они еще не то вам обоснуют - лишь бы оптимизацию платформы не делать.
Статейки писать - не думать и делом заниматься.
ага. Особенно при прямых запросах.
вот когда сами разработчики конф и платформы выучат свои же "планы запросов, правильная индексация и использование временных таблиц" - вот тогда и будем разговаривать про все это.
А сейчас - чисто логика: либо они не знают и не используют, что это такое и как работает, либо - оно используется, но работает из рук вон плохо.
Даже не буду в дальнейшие детали вдаваться по поводу "планов запросов, правильной индексации и использование временных таблиц".
А то каждое поколение студентов - учи заново. Учитесь сами, в конце концов.
слушайте, я уже устал с вами, студентами, бороться - или учите, что такое индексация, реляционная модель, ключи, или читайте и дальше агитки от 1С.
Они еще не то вам обоснуют - лишь бы оптимизацию платформы не делать.
Статейки писать - не думать и делом заниматься.
7.7 - работает с СКЛ просто ужасно
ага. Особенно при прямых запросах.
Из практики могу сказать, что изучение планов запросов, правильная индексация и использование временных таблиц
вот когда сами разработчики конф и платформы выучат свои же "планы запросов, правильная индексация и использование временных таблиц" - вот тогда и будем разговаривать про все это.
А сейчас - чисто логика: либо они не знают и не используют, что это такое и как работает, либо - оно используется, но работает из рук вон плохо.
Даже не буду в дальнейшие детали вдаваться по поводу "планов запросов, правильной индексации и использование временных таблиц".
А то каждое поколение студентов - учи заново. Учитесь сами, в конце концов.
(47) AlexO,
С Вами все ясно.
Любимые способы ведения полемики:
1) переход на личности: "слушайте, я уже устал с вами, студентами, бороться"
2) Шквальная критика чужой позиции, а не защита своей: "Они еще не то вам обоснуют - лишь бы оптимизацию платформы не делать.
Статейки писать - не думать и делом заниматься."
К сведению: я не студент и имею большой опыт работы с 1с. Как я говорил ранее, в том числе и с системами крупных федеральных сетей.
Зачем изучать особенности платформы, средства ее оптимизации, когда можно заявить что "это 1С виновато!".
Я знаю одно: создание индексов в СУБД 1С задокументировано и оно реально так работает.
описанные методы оптимизации работают и позволяют строить эффективные инструменты.
1С свои запросы достаточно корректно транслирует в SQL запросы, дальнейшая работа оптимизатора это дело СУБД (они кстати по разному работают в МС, ПГ, ДБ2 и Оракле).
то что вы пишете это выпускание пара и эмоции, не подкрепленные ни фактами ни доказательствами.
Тот кто хочет работать эффективно с 1С найдет способ как это сделать,
кто не хочет, обвинит всех вокруг и найдет 1000 причин почему это невозможно.
ЗЫ: опровергните довод: "МС овно, их СКЛ работает криво!
- 5 лет не могли исправить проблему!
Лучше бы ошибки исправляли нежели красявости в висте разрисовывать!"
По теме:
Если нужно ограничить доступ к документам в 1-2 формах, то проще в коде установить предопределенные отборы по заданным полям.
Если нужно гарантированное сокрытие информации для получения любыми путями: в списках, отчетах, обработках то РЛС.
Сам по себе РЛС, конечно же требует некоторые ресурсы и замедляет работу систем. Но катастрофического падения производительности не наблюдалось - многое зависит от сложности накладываемых условий.
Самая большая проблема в настройке это отладка. Требуется полная проверка работы всех ролей с ограничиваемыми данными. А т.к. отладчика нет и сообщений к какой таблице нет доступа, зачастую приходится доставать бубен для поиска ошибок.
С Вами все ясно.
Любимые способы ведения полемики:
1) переход на личности: "слушайте, я уже устал с вами, студентами, бороться"
2) Шквальная критика чужой позиции, а не защита своей: "Они еще не то вам обоснуют - лишь бы оптимизацию платформы не делать.
Статейки писать - не думать и делом заниматься."
К сведению: я не студент и имею большой опыт работы с 1с. Как я говорил ранее, в том числе и с системами крупных федеральных сетей.
Зачем изучать особенности платформы, средства ее оптимизации, когда можно заявить что "это 1С виновато!".
Я знаю одно: создание индексов в СУБД 1С задокументировано и оно реально так работает.
описанные методы оптимизации работают и позволяют строить эффективные инструменты.
1С свои запросы достаточно корректно транслирует в SQL запросы, дальнейшая работа оптимизатора это дело СУБД (они кстати по разному работают в МС, ПГ, ДБ2 и Оракле).
то что вы пишете это выпускание пара и эмоции, не подкрепленные ни фактами ни доказательствами.
Тот кто хочет работать эффективно с 1С найдет способ как это сделать,
кто не хочет, обвинит всех вокруг и найдет 1000 причин почему это невозможно.
ЗЫ: опровергните довод: "МС овно, их СКЛ работает криво!
- 5 лет не могли исправить проблему!
Лучше бы ошибки исправляли нежели красявости в висте разрисовывать!"
По теме:
Если нужно ограничить доступ к документам в 1-2 формах, то проще в коде установить предопределенные отборы по заданным полям.
Если нужно гарантированное сокрытие информации для получения любыми путями: в списках, отчетах, обработках то РЛС.
Сам по себе РЛС, конечно же требует некоторые ресурсы и замедляет работу систем. Но катастрофического падения производительности не наблюдалось - многое зависит от сложности накладываемых условий.
Самая большая проблема в настройке это отладка. Требуется полная проверка работы всех ролей с ограничиваемыми данными. А т.к. отладчика нет и сообщений к какой таблице нет доступа, зачастую приходится доставать бубен для поиска ошибок.
(1) serq82,
по подразделениям, складам, пользвателям - есть.
По кассам - веротней всего в вашей конфе нет.
Нужно дописывать.
__________________________________
Вы неправильно подходите к задаче.
Если поставлено ограничить ВЕЗДЕ - то только RLS, без вариантов. А если конкретные документы/справочники/регистры - попробуйте через роли и код.
И не увлекайтесь RLS - с вашими намерениями органичить "и здесь, и здесь, и там" у вас, в первую очередь, возникунт проблемы не с тормозами, а с невозможностью доступа и у тех, кому вроде как должно быть разрешено.
RLS - крайне коварная штука, и пользоваться им нужно очень осторожно и дозировано.
делаю настройки доступа к документам для ролей,задача стоит ограничить по подразделениям, складам, кассам, ответственным
по подразделениям, складам, пользвателям - есть.
По кассам - веротней всего в вашей конфе нет.
Нужно дописывать.
__________________________________
Вы неправильно подходите к задаче.
Если поставлено ограничить ВЕЗДЕ - то только RLS, без вариантов. А если конкретные документы/справочники/регистры - попробуйте через роли и код.
И не увлекайтесь RLS - с вашими намерениями органичить "и здесь, и здесь, и там" у вас, в первую очередь, возникунт проблемы не с тормозами, а с невозможностью доступа и у тех, кому вроде как должно быть разрешено.
RLS - крайне коварная штука, и пользоваться им нужно очень осторожно и дозировано.
Использую у себя в УПП следующие способы организации RLS:
Текст запроса для ограничения по подразделению и организации:
"ГДЕ
&ПолныеПрава
ИЛИ
(НЕ &ИспользоватьОграничениеПоОрганизации И НЕ &ИспользоватьОграничениеПоПодразделения)
ИЛИ
(НЕ &ИспользоватьОграничениеПоОрганизации ИЛИ #Параметр(1) В (&НастройкиПравДоступаПользователей_Организации))
И (НЕ &ИспользоватьОграничениеПоПодразделения ИЛИ #Параметр(2) В (&НастройкиПравДоступаПользователей_Подразделения))"
Обращение к rls в роли #ОрганизацияПодразделение("Организация","Подразделение")
Параметры сеанса, задаются в модуле сеанса:
ПолныеПрава - задаю если не нужно использовать RLS для пользователя
ИспользоватьОграничениеПоОрганизации - истина, если использую ограничение по организациям для пользователя
НастройкиПравДоступаПользователей_Организации - массив доступных организаций
ИспользоватьОграничениеПоПодразделения - истина, если использую ограничение по подразделениям для пользователя
НастройкиПравДоступаПользователей_Подразделения - массив доступных подразделений
Используя массивы добился ускорения работы по сравнению с типовыми запросами RLS использующими выборку из регистров и справочников
Текст запроса для ограничения по подразделению и организации:
"ГДЕ
&ПолныеПрава
ИЛИ
(НЕ &ИспользоватьОграничениеПоОрганизации И НЕ &ИспользоватьОграничениеПоПодразделения)
ИЛИ
(НЕ &ИспользоватьОграничениеПоОрганизации ИЛИ #Параметр(1) В (&НастройкиПравДоступаПользователей_Организации))
И (НЕ &ИспользоватьОграничениеПоПодразделения ИЛИ #Параметр(2) В (&НастройкиПравДоступаПользователей_Подразделения))"
Обращение к rls в роли #ОрганизацияПодразделение("Организация","Подразделение")
Параметры сеанса, задаются в модуле сеанса:
ПолныеПрава - задаю если не нужно использовать RLS для пользователя
ИспользоватьОграничениеПоОрганизации - истина, если использую ограничение по организациям для пользователя
НастройкиПравДоступаПользователей_Организации - массив доступных организаций
ИспользоватьОграничениеПоПодразделения - истина, если использую ограничение по подразделениям для пользователя
НастройкиПравДоступаПользователей_Подразделения - массив доступных подразделений
Используя массивы добился ускорения работы по сравнению с типовыми запросами RLS использующими выборку из регистров и справочников
Использование RLS (правда, без фанатизма) дало небольшой выигрыш в производительности в сравнении с самописными ограничениями. По моему скромному мнению, чем больше будет накручиваться RLS, тем меньше от неё будет толку (в плане производительности), но это сугубо мое мнение, ничем на практике не подтвержденное.
P.S. Немного не в тему, но хотел бы заметить:
Не совсем понятно, что вы имеете в виду. С точки зрения СУБД таблицы данных 1С вполне себе проиндексированы (порой даже излишне).
P.S. Немного не в тему, но хотел бы заметить:
А что касается самих индексов - то никакой индексации таблиц (регистров, документов) в БД 1С нет и не было. Поделку в виде "индексации" измерений даже рассматривать не стоит - это фикция.
Не совсем понятно, что вы имеете в виду. С точки зрения СУБД таблицы данных 1С вполне себе проиндексированы (порой даже излишне).
Да я же уже сдался! :)
Так в "отплевку" скажу что у записи таблиц документов в БД (как и улюбого ссылочного) есть поле _IDRRef по которому он идентифицруется. Для регистров - используется сосотавной первичный ключь (комбинация измерений + период).
Кроме того в самом собщение "накидано" разные понятия из конфигурации ("объект") и базы данных ("однозначно идентифицируется") - все в кучу. Но если идет речь по однозначному идентификатору объекта метаданных (не путать с записью БД) то и такое есть.
Впрочем, я уже говорил, что лапки задраны :) А "лажачих не бьют" :)
Так в "отплевку" скажу что у записи таблиц документов в БД (как и улюбого ссылочного) есть поле _IDRRef по которому он идентифицруется. Для регистров - используется сосотавной первичный ключь (комбинация измерений + период).
Кроме того в самом собщение "накидано" разные понятия из конфигурации ("объект") и базы данных ("однозначно идентифицируется") - все в кучу. Но если идет речь по однозначному идентификатору объекта метаданных (не путать с записью БД) то и такое есть.
Впрочем, я уже говорил, что лапки задраны :) А "лажачих не бьют" :)
(35) Ягг,
это у вас накидано, я-то прекрасно знаю, кто работает с объектами иссылками, а кто - с индексами и ключами :)
идентифицируется не объект, а часть данных объекта - чтобы получить его "целиком", SQL и возвращает все данные из связанных таблиц по запросу "объект", а уже 1С-сервер собирает весь этот "конструктор" воедино для обработки.
SQL же ничего не знает об "объектах", ссылках и прочих "изысках" от 1С. А просто возвращает все, что у него есть в рамках реляционной модели базы по данному вопросу.
да никто вас не бьет :)
Вы-то хоть в профайлер заглянули одним глазком.
А вопросы "ООП в 1С", "RLS - как два пальца", "реляционная БД 1С" возникают постоянно. И чем дальше - тем чаще.
"накидано" разные понятия из конфигурации ("объект") и базы данных ("однозначно идентифицируется")
это у вас накидано, я-то прекрасно знаю, кто работает с объектами иссылками, а кто - с индексами и ключами :)
_IDRRef по которому он идентифицруется
идентифицируется не объект, а часть данных объекта - чтобы получить его "целиком", SQL и возвращает все данные из связанных таблиц по запросу "объект", а уже 1С-сервер собирает весь этот "конструктор" воедино для обработки.
SQL же ничего не знает об "объектах", ссылках и прочих "изысках" от 1С. А просто возвращает все, что у него есть в рамках реляционной модели базы по данному вопросу.
А "лажачих не бьют"
да никто вас не бьет :)
Вы-то хоть в профайлер заглянули одним глазком.
А вопросы "ООП в 1С", "RLS - как два пальца", "реляционная БД 1С" возникают постоянно. И чем дальше - тем чаще.
Если честно, то было безумно интересно вас почитать, я только еще потихоньку изучаю 1с, какие-то вещи понимаю, какие-то нет...
Пока RLS мне не поддается, пару раз бралась разобраться, но моего терпения не хватало. Посоветуйте какие-нибудь умные книжки по RLS.
Пока RLS мне не поддается, пару раз бралась разобраться, но моего терпения не хватало. Посоветуйте какие-нибудь умные книжки по RLS.
(41) Ammy80,
их не существует в природе, т.к. когда 1с сбацала свой RLS, то оно как-бы все было опытное и обкатывалось, а потом, как у 1с зачастую бывает, приоритеты сменились, и документация по RLS тихо "забылась".
Лично у меня есть только опыт и записи.
Но даже и это не помогает в новой УПП, где методика создания запросов RLS опять сменилась и стала еще более непонятной.
Посоветуйте какие-нибудь умные книжки по RLS.
их не существует в природе, т.к. когда 1с сбацала свой RLS, то оно как-бы все было опытное и обкатывалось, а потом, как у 1с зачастую бывает, приоритеты сменились, и документация по RLS тихо "забылась".
Лично у меня есть только опыт и записи.
Но даже и это не помогает в новой УПП, где методика создания запросов RLS опять сменилась и стала еще более непонятной.
ух, ребята...
каждый имеет право на свое мнений..
я исхожу из определения сервера баз данных (википедия).
вобщем ладно, если заказчики удовлетворены вашими программами - то это главное :)
Зы. Если нужна какая-то конкретика (которую можно показать и проверить) - всегда пожалуста с удовольствием обсужу. А "теорию понятий", эмоции - честно, не охото (я не Даль, у меня на это терпения не хватит :) )
каждый имеет право на свое мнений..
я исхожу из определения сервера баз данных (википедия).
Сервер БД обслуживает базу данных и отвечает за целостность и сохранность данных, а также обеспечивает
операции ввода-вывода при доступе клиента к информации.
вобщем ладно, если заказчики удовлетворены вашими программами - то это главное :)
Зы. Если нужна какая-то конкретика (которую можно показать и проверить) - всегда пожалуста с удовольствием обсужу. А "теорию понятий", эмоции - честно, не охото (я не Даль, у меня на это терпения не хватит :) )
Я бы не советовал, ибо:
1) Замедляет работу базы.
2) В типовых конфигурациях постоянные косяки с RLS.
3) Если изменишь типовые роли, то обновления ролей крайне неудобная штука.
4) Нормальной отладки rls в 1с нету.
Вообще у нас сейчас упп, ограничения по организациям, физ.лицам, подразделениям, складам. Из-за этого часто возникают проблемы.
1) Замедляет работу базы.
2) В типовых конфигурациях постоянные косяки с RLS.
3) Если изменишь типовые роли, то обновления ролей крайне неудобная штука.
4) Нормальной отладки rls в 1с нету.
Вообще у нас сейчас упп, ограничения по организациям, физ.лицам, подразделениям, складам. Из-за этого часто возникают проблемы.
(58) serq82,
Ну на процентов 10-20. Но то что я говорю это все ооочень относительно. Нужно понимать в принципе насколько у тебя сейчас торговля быстро работает, а это зависит от сервера, сети, насколько перелапачена у тебя УТ.
Вообщем в УТ10 очень косячно сделано типовое rls, вот попробуй в демо базе дать человеку роль пользователь, менеджер по продажам, менеджер по закупкам и сразу все увидишь.
Ну на процентов 10-20. Но то что я говорю это все ооочень относительно. Нужно понимать в принципе насколько у тебя сейчас торговля быстро работает, а это зависит от сервера, сети, насколько перелапачена у тебя УТ.
Вообщем в УТ10 очень косячно сделано типовое rls, вот попробуй в демо базе дать человеку роль пользователь, менеджер по продажам, менеджер по закупкам и сразу все увидишь.
(59) artur.antipin,несколько ролей конечно не пробывал,но я стараюсь заводить отдельную роль и в ней дать нужное и ограничить...меня вообще поразило у 1с-ков как они раздают права по пользователям.с какой интересно колокольни берут? у роли пользователь есть доступ к контрагенты,у менеджера по продажам нет...)))
и все таки как лучше сделать?использовать RSL или отказаться и искать другие способы?
и все таки как лучше сделать?использовать RSL или отказаться и искать другие способы?
и все это:
Я насколько помню - 1С в течении нескольких лет рекомендовало учитывать купленную типовую программу на счете 04 "Нематериальные активы". Потом бах - и резко изменили свое мнение... А сколько народа ввели в заблуждение?
Ладно, другой пример. На днях пришли на консультацию коллеги. Один из вопросов - как учитывать пять полученных печатей и штампов при открытии фирмы.
С точки зрения ПБУ 6/01 - это основные средства. То же ПБУ разрешает их учитывать как материалы (но не более 40 000 рублей за единицу). Данный конктретный учет зависит от учетной политики. Все зависит от Вас - и так правильно, и по другому - правильно.
Но если поставите на 10.09, то при передаче в эксплуатацию они "упадут" на счет МЦ, который крайне неудобен для инвентаризации (иначе говоря инвентаризацию нормально по МЦ - не сделать).
Руководитель сказал: "В Советское время даже пепельницы учитывали в составе ОС, а не в составе МБП (было и такой учет), при этом они еще и амортизировались. И все это делалось вручную и был порядок! А сейчас - списали сразу и с бухгалтерского и с налогового - дальше - забыли - вот вам и бардак с ходу. А ноутбука недавно хватились (по другой фирме) - нету...А вроде бы инвентаризации все провели...Такие вещи будем держать всегда на балансе!"
Ну что ж - решение руководителя есть решение. Это его выбор учета, который разрешен законодательно.Да и скорее всего он прав.
Возьмем другой пример - двигатели. Когда организация приобретает самолет, трактор или "Камаз" - она ставит его целиком как единый инвентарный объект с единым сроком полезного использования. Но приходит время и начинается замена этих двигателей. Приобретаются новые двигатели. И оказывается что срок полезного использования у них разный (в отличие от ранее приобретенного основного средства). И вот начинается... Минфин сыпет противоречивые письма как их учитывать. Например, письмо от 20 февраля 2008 г. N 03-03-06/1/121, где "В силу этого авиационные двигатели гражданской авиации, срок полезного использования которых отличается от срока полезного использования воздушного судна, учитываются как отдельные инвентарные объекты". Да, конечно отличаются и сильно, но тогда по логике минфина нужно сразу при принятии к учету самолета - разбить самолет в бухгалтерском учете на части. Но где взять стоимость двигателя? При этом нужно учесть стоимость не только двигателя отдельно, но и стоимость его установки на заводе-изготовителе...
Так же и с тракторами. Например, копровая установка (грубо говоря - сваебойка).
Так же и с автомобилями. На любой автобазе есть "оборотные" двигатели. И на нормальной автобазе смена двигателя на машине происходит раз в 2-3 года (если машине более 5 лет). Пробовал ли кто-то реально отражать данный капремонт не вникнув в специфику?
В принципе, все можно решить грамотно составленной учетной политикой - нельзя жестко ссылаться на План счетов, ИТС, письма Минфин и др. органов. У каждой организации своя специфика. А письма, распоряжения, рекомендации - это (в основном на 99%) ненормативные документы. Напомню, что нормативные документы это те, которые действуют на всех без разбора и которые регистрируются в МинЮсте.
А нестандартные операции у нас на каждом шагу...
Последний пример. Про танки. Танки могут учитываться на 43, если они являются вашей готовой продукцией, танки могут учитываться на 41 если вы ими торгуете, танки могут учитываться на 08 и 01 если они ваши. Но могут ли танки учитываться на 10-м?
По вопросу учета танков обратился крупный металлургический завод. Дело в том, что согласно приказа МО РФ (не помню номер - было лет 8 назад), танки должны передаваться с воинских частей для утилизации не по товарным накладным, а по актам передачи ОС. Ну чтож - логика есть - каждый танк имеет разную сталь, могут идти с двигателями и т.д. Но приходовать завод их не может как металлолом - они же еще не разобраны, да и переданы как танки - и документы - на танки. Что делать? Куда их толкать на 08 что-ли?
А аудиторам что делать? Пришлось признать что да, вы делаете верно - танки в данном случае должны учитываться на 10-м, а после разделки выйдут материалы и полуфабрикаты на 10-й и 21-й.
Совет.Двух аналогичных ситуаций не бывает, всегда нужно подумать своей головой над корреспонденцией счетов. Чтобы логика была. Придумали? Но если Вы не специалист - советуйтесь.
Найти красивую книжку с названием типа "100001 проводка" несложно, но вашей ситуации там не будет...
К чему???к чему все это????????
Я насколько помню - 1С в течении нескольких лет рекомендовало учитывать купленную типовую программу на счете 04 "Нематериальные активы". Потом бах - и резко изменили свое мнение... А сколько народа ввели в заблуждение?
Ладно, другой пример. На днях пришли на консультацию коллеги. Один из вопросов - как учитывать пять полученных печатей и штампов при открытии фирмы.
С точки зрения ПБУ 6/01 - это основные средства. То же ПБУ разрешает их учитывать как материалы (но не более 40 000 рублей за единицу). Данный конктретный учет зависит от учетной политики. Все зависит от Вас - и так правильно, и по другому - правильно.
Но если поставите на 10.09, то при передаче в эксплуатацию они "упадут" на счет МЦ, который крайне неудобен для инвентаризации (иначе говоря инвентаризацию нормально по МЦ - не сделать).
Руководитель сказал: "В Советское время даже пепельницы учитывали в составе ОС, а не в составе МБП (было и такой учет), при этом они еще и амортизировались. И все это делалось вручную и был порядок! А сейчас - списали сразу и с бухгалтерского и с налогового - дальше - забыли - вот вам и бардак с ходу. А ноутбука недавно хватились (по другой фирме) - нету...А вроде бы инвентаризации все провели...Такие вещи будем держать всегда на балансе!"
Ну что ж - решение руководителя есть решение. Это его выбор учета, который разрешен законодательно.Да и скорее всего он прав.
Возьмем другой пример - двигатели. Когда организация приобретает самолет, трактор или "Камаз" - она ставит его целиком как единый инвентарный объект с единым сроком полезного использования. Но приходит время и начинается замена этих двигателей. Приобретаются новые двигатели. И оказывается что срок полезного использования у них разный (в отличие от ранее приобретенного основного средства). И вот начинается... Минфин сыпет противоречивые письма как их учитывать. Например, письмо от 20 февраля 2008 г. N 03-03-06/1/121, где "В силу этого авиационные двигатели гражданской авиации, срок полезного использования которых отличается от срока полезного использования воздушного судна, учитываются как отдельные инвентарные объекты". Да, конечно отличаются и сильно, но тогда по логике минфина нужно сразу при принятии к учету самолета - разбить самолет в бухгалтерском учете на части. Но где взять стоимость двигателя? При этом нужно учесть стоимость не только двигателя отдельно, но и стоимость его установки на заводе-изготовителе...
Так же и с тракторами. Например, копровая установка (грубо говоря - сваебойка).
Так же и с автомобилями. На любой автобазе есть "оборотные" двигатели. И на нормальной автобазе смена двигателя на машине происходит раз в 2-3 года (если машине более 5 лет). Пробовал ли кто-то реально отражать данный капремонт не вникнув в специфику?
В принципе, все можно решить грамотно составленной учетной политикой - нельзя жестко ссылаться на План счетов, ИТС, письма Минфин и др. органов. У каждой организации своя специфика. А письма, распоряжения, рекомендации - это (в основном на 99%) ненормативные документы. Напомню, что нормативные документы это те, которые действуют на всех без разбора и которые регистрируются в МинЮсте.
А нестандартные операции у нас на каждом шагу...
Последний пример. Про танки. Танки могут учитываться на 43, если они являются вашей готовой продукцией, танки могут учитываться на 41 если вы ими торгуете, танки могут учитываться на 08 и 01 если они ваши. Но могут ли танки учитываться на 10-м?
По вопросу учета танков обратился крупный металлургический завод. Дело в том, что согласно приказа МО РФ (не помню номер - было лет 8 назад), танки должны передаваться с воинских частей для утилизации не по товарным накладным, а по актам передачи ОС. Ну чтож - логика есть - каждый танк имеет разную сталь, могут идти с двигателями и т.д. Но приходовать завод их не может как металлолом - они же еще не разобраны, да и переданы как танки - и документы - на танки. Что делать? Куда их толкать на 08 что-ли?
А аудиторам что делать? Пришлось признать что да, вы делаете верно - танки в данном случае должны учитываться на 10-м, а после разделки выйдут материалы и полуфабрикаты на 10-й и 21-й.
Совет.Двух аналогичных ситуаций не бывает, всегда нужно подумать своей головой над корреспонденцией счетов. Чтобы логика была. Придумали? Но если Вы не специалист - советуйтесь.
Найти красивую книжку с названием типа "100001 проводка" несложно, но вашей ситуации там не будет...
К чему???к чему все это????????
(72) serq82,
ну я понимаю - если бы спросили про "RLS, роли, ограничения на колонки и общие реквизиты" - было бы простительно :)
Но вопросом про RLS и отборы вы ставите меня в тупик.
Отборы чего и зачем? Справочника, списка, выборки, регистра, ПостроителяОтчета, КритерииОтбора или чего отборы-то?
ну я понимаю - если бы спросили про "RLS, роли, ограничения на колонки и общие реквизиты" - было бы простительно :)
Но вопросом про RLS и отборы вы ставите меня в тупик.
Отборы чего и зачем? Справочника, списка, выборки, регистра, ПостроителяОтчета, КритерииОтбора или чего отборы-то?
(75) serq82, что отбор, что RLS все заканчивается запросом к БД с фильтром данных. Главное не назначайте пользователям нескольких ролей с RLS: на больших объемах данных будут тормоза, а создайте новую роль и настройте в ней доступ на уровне записей таким образом, чтобы она отвечала предъявляемым к ней требованиям.
(78) serq82, к сожалению с управляемыми формами имел дело пару раз, поэтому не подскажу. Чем RLS еще удобней и лучше отборов: отборами вы все дырки не закроете, в отчетах адеватно не повставляетесь и т.д., а RLS накладывается платформой в момент трансформации 1с-ких запросов к БД и поэтому всегда гарантированно пользователь получит только те записи, на котрорые есть у него права. Еще раз повторюсь, что необходимо для более быстрой работы создать одну роль для пользователя и в ней настроить доступ к нужным объектам с помощью RLS.
(86) serq82,
вы читаете через две строчки :)
Запросы и все прочие обращения в УФ - только на сервере (в чем и идиотизм, но это тема отдельного разговора), RLS - добавляет к запросам объектов - свои условия на ограничение. Следовательно - RLS автоматически работают только на сервере, если можно так сказать. Больше никак невозможно по условиям работы УФ.
(87) sai_NT,
боюсь, он опять не поймет :)
serq82, разделите для начала свой код на клиента и сервер, а выполнение RLS получится автоматом - они к УФ никакого отношения не имеют, а работают с обращениями сервера к БД.
запросы на клиенте не работают...тогда получается рсл даже удобнее в управляемых формах (вроде) или я ошибаюсь?
вы читаете через две строчки :)
Запросы и все прочие обращения в УФ - только на сервере (в чем и идиотизм, но это тема отдельного разговора), RLS - добавляет к запросам объектов - свои условия на ограничение. Следовательно - RLS автоматически работают только на сервере, если можно так сказать. Больше никак невозможно по условиям работы УФ.
(87) sai_NT,
запросы к БД в случае клиент-сервера выполняются только на сервере!
боюсь, он опять не поймет :)
serq82, разделите для начала свой код на клиента и сервер, а выполнение RLS получится автоматом - они к УФ никакого отношения не имеют, а работают с обращениями сервера к БД.
(84) serq82,
Еще неизвестно, как взлетит БП 3.0 - она все еще тестовая-бета, только тру-1сники в ней работают, да бухов туда гонят, которым не повезло устроится к нормальным 1с-никам. Насколько даже она хотя бы приблизилась к БП 1.6 - 2.0 много подгадила, да еще эти ненормальные УФ...
А про ЗУП и говориить нечего - вон, обновление последнего релиза 2.5.52.1 (и безо всяких УФ) зачистил регистры расчета в рабочих базах. Отозваны релизы ЗУП, ЗУПБУ и УПП. Выпущены новые релизы, в которых снова ошибки (менее критичные), и планируют отозвать и эти - ждем обновления с номером .3 на конце.
Так что все эти УФ - это только потеря клиентов.
Бухи и так массово перебираются в другие программы для сдачи отчетности - как накопится критическая масса "а что у нас в 1с осталось?", так и начнут тормозить всю эту вакханалию, и заставят, наконец, 1с заняться дело, а не идиотскими "УФ, облака, потестите наш новый релиз".
Сколько мы не получали обновление, ломающее базу? Ну вот, дождались.
Подобные контроль за разработкой и ответственность за продукты 1С - это уже их корпоративный стиль, если кто сомневается.
А студенты пусть и дальше ждут. Что им, студентам, делать? :)
да их никто не видел - там переведены только модули: Склад, Продажи, учет и анализ Затрат, частично Производство.
Еще неизвестно, как взлетит БП 3.0 - она все еще тестовая-бета, только тру-1сники в ней работают, да бухов туда гонят, которым не повезло устроится к нормальным 1с-никам. Насколько даже она хотя бы приблизилась к БП 1.6 - 2.0 много подгадила, да еще эти ненормальные УФ...
А про ЗУП и говориить нечего - вон, обновление последнего релиза 2.5.52.1 (и безо всяких УФ) зачистил регистры расчета в рабочих базах. Отозваны релизы ЗУП, ЗУПБУ и УПП. Выпущены новые релизы, в которых снова ошибки (менее критичные), и планируют отозвать и эти - ждем обновления с номером .3 на конце.
Так что все эти УФ - это только потеря клиентов.
Бухи и так массово перебираются в другие программы для сдачи отчетности - как накопится критическая масса "а что у нас в 1с осталось?", так и начнут тормозить всю эту вакханалию, и заставят, наконец, 1с заняться дело, а не идиотскими "УФ, облака, потестите наш новый релиз".
Сколько мы не получали обновление, ломающее базу? Ну вот, дождались.
Подобные контроль за разработкой и ответственность за продукты 1С - это уже их корпоративный стиль, если кто сомневается.
А студенты пусть и дальше ждут. Что им, студентам, делать? :)
УПП и КА на управляемых формах
да их никто не видел - там переведены только модули: Склад, Продажи, учет и анализ Затрат, частично Производство.
(88) AlexO, я больше сисадмин чем 1с-к,1с тока изучаю,но чую что будущее за УФ,как ты не крути все равно все прийдет к этому,и думаю до конца года бух 3 допишут и оставят на поддержки только ее.тут еще и про платформу 8.3 поговаривают.я за новостями не слежу,но мне кажется идет то же самое что с бух 1.6 на 2.0...
(75) serq82,
RLS работает при любом вызове обусловленного объекта, отборы - только на родительском объекте.
Если RLS убрать, а сделать какой-то один отбор - то и ограничивать будет только в данном конкретном списке/запросе, а не во всех объектах, которые так или иначе берут данные по подразделениям, кассам и складам.
(76) sai_NT,
есть небольшое отличие.
отбор создает один запрос - выборку к данным (сразу с условиями), а RLS - добавляет свои ограничения к другим запросам, сужая их рамки.
RLS работает при любом вызове обусловленного объекта, отборы - только на родительском объекте.
Если RLS убрать, а сделать какой-то один отбор - то и ограничивать будет только в данном конкретном списке/запросе, а не во всех объектах, которые так или иначе берут данные по подразделениям, кассам и складам.
(76) sai_NT,
что отбор, что RLS все заканчивается запросом к БД с фильтром данных.
есть небольшое отличие.
отбор создает один запрос - выборку к данным (сразу с условиями), а RLS - добавляет свои ограничения к другим запросам, сужая их рамки.
где-то выше писалось про отсутствие аналогов РЛСа..
Детище это Оракла образца 98года (opracle 8i). Зовется, соответственно, row-level security. Живёт там и здравствует. На sql.ru , что вроде и MS обещались добавить в 2005/2008 - но чото не срослось
ссылки в тему
Детище это Оракла образца 98года (opracle 8i). Зовется, соответственно, row-level security. Живёт там и здравствует. На sql.ru , что вроде и MS обещались добавить в 2005/2008 - но чото не срослось
ссылки в тему
(92) romansun,
я писал.
Какое отношение имеет RLS в 1С к остальным "похожим" технологиям?
А если не можете прочитать как следует - так и скажите.
Повторю - отдельно для вас.
Аналога RLS в СУБД SQL нет. Это целиком разработка 1С в сервере 1С.
Или там Оракла разработки используются?
А может - вы знаете способ подключать модульно функции СУБД Oracle для обработки 1С-баз?
Неужели нет? ай-яй-яй...
Так что все ваши ссылки никакого отношения не имеют к 1С RLS. Ни от Оракла, ни от SQL.
Тем более - все указанные вами RLS реализованы в реляционных СУБД, когда как в 1С - RLS накладывается на объекты.
Поэтому - даже если в SQL сделают RLS (свой), в 1с-е его использовать не смогут.
я писал.
Какое отношение имеет RLS в 1С к остальным "похожим" технологиям?
А если не можете прочитать как следует - так и скажите.
Повторю - отдельно для вас.
Аналога RLS в СУБД SQL нет. Это целиком разработка 1С в сервере 1С.
Или там Оракла разработки используются?
А может - вы знаете способ подключать модульно функции СУБД Oracle для обработки 1С-баз?
Неужели нет? ай-яй-яй...
Так что все ваши ссылки никакого отношения не имеют к 1С RLS. Ни от Оракла, ни от SQL.
Тем более - все указанные вами RLS реализованы в реляционных СУБД, когда как в 1С - RLS накладывается на объекты.
Поэтому - даже если в SQL сделают RLS (свой), в 1с-е его использовать не смогут.
(95) Alav,
если не поняли - прочитайте название темы.
А также - вопрос ТС. Он звучит как "Есть ли еще где какие RLS в мире СУБД"? Нет?
Он звучит как "Ут 10. Делаю настройки доступа к документам ..."
Неужели УТ10 появилась и в Оракл? Нет?
Тогда откуда вы прилетаете последнюю неделю с непонятно к чему привязанными вопросами? :)
если не поняли - прочитайте название темы.
А также - вопрос ТС. Он звучит как "Есть ли еще где какие RLS в мире СУБД"? Нет?
Он звучит как "Ут 10. Делаю настройки доступа к документам ..."
Неужели УТ10 появилась и в Оракл? Нет?
Тогда откуда вы прилетаете последнюю неделю с непонятно к чему привязанными вопросами? :)
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот