RLS — дубли условий в запросах к СУБД
«Подводные камни», возникающие при бездумном копировании ролей с ограничениями RLS, как это отражается на производительности, разбор примера и инструмент для анализа.
- Описание
- Подробнее
Описание
Для тех, кто не в курсе
RLS или Record Level Security или Доступ на уровне записи, механизм призванный сделать оптимальным процесс ограничения доступа к данным в зависимости от их наполнения, например, в документе один из реквизитов — филиал, при настройке ограничений RLS, можно ограничить просмотр документов с определенным составом филиалов для каждого пользователя индивидуально.
Как-то недавно на базе 1С:ЗУП, немного доработанной, я столкнулся с ошибкой, когда MSSQL Server отказался формировать запрос ввиду его большого размера. Анализ показал, что 1С действительно формирует огромный запрос, более 1000 строк (сейчас точнее уже не помню) и весомую часть запроса составляли добавленные ограничения RLS. Базу дорабатывало крупное франчайзи и специалисты у них неплохие, однако и они "наступили на грабли".
Тестовый пример
Для теста написана простая конфигурация, справочники:
- "Филиалы"
- "Пользователи" (Табличная часть "ФилиалыРазрешенные", в ней реквизит "Филиал" для установки пользователю разрешенных филиалов)
документ:
- "Передача денег", реквизиты "Филиал", "Сумма"
роли:
- "Полные права" — без ограничений RLS
- "Бухгалтер", "ИЗМ_Бухгалтер", "ИЗМ_БухгалтерПоФилиалам" имеют идентичное по смыслу ограничение RLS по филиалам на чтение документа "Передача денег", в каждой RLS-роли добавлено незначительное изменение (Условие 1 = 1, 2 = 2 и т.д.).
Пользователь с ограниченными правами, будет видеть только документы разрешенных ему филиалов. В качестве теста будем использовать форму списка вышеуказанного документа, будем ее обновлять по F5 и смотреть трассировку запросов в SQL Profiler.

