Спасибо всем за создание форума и концентрацию на нем полезной для разработчиков информации!

Не нашла темы по RLS запросам в ролях пользователей, возможно плохо искала.

RLS запросы удобная вещь, но они очень существенно влияют на быстродействие системы в файловом варианте.

В типовой конфигурации УПП есть такая конструкция :

АктОбОказанииПроизводственныхУслуг ГДЕ (АктОбОказанииПроизводственныхУслуг.Контрагент = ЗНАЧЕНИЕ(Справочник.Контрагенты.ПустаяСсылка)
            ИЛИ 1 В
                (ВЫБРАТЬ ПЕРВЫЕ 1
                    1
                ИЗ
                    РегистрСведений.ПраваДоступаПользователейКОбъектам КАК ПраваДоступаПользователейКОбъектам
                ГДЕ
                    ПраваДоступаПользователейКОбъектам.ОбъектДоступа = АктОбОказанииПроизводственныхУслуг.Контрагент
                    И ПраваДоступаПользователейКОбъектам.ОбластьДанных = ЗНАЧЕНИЕ(Перечисление.ОбластиДанныхОграниченияПравДоступа.КонтрагентыДанные)
                    И ПраваДоступаПользователейКОбъектам.Пользователь В (&ГруппыТекущегоПользователя)
                    И ПраваДоступаПользователейКОбъектам.Чтение = ИСТИНА))

Она формирует ограничения по реквизиту Контрагент в Акте для данного пользователя.
Не все реквизиты, по которым нужно ограничивать доступ пользователю есть в регистре ПраваДоступаПользователей, и некоторые из ограничений можно прописывать , пользуясь регистром НастройкиПользователей
Для своей задачи я прописала такой запрос:

Шапка ИЗ Документ.ЗаказПокупателя КАК Шапка
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ РегистрСведений.НастройкиПользователей КАК НастройкиПользователей
    ПО (НастройкиПользователей.Пользователь = &ТекущийПользователь)
        И (НастройкиПользователей.Настройка = ЗНАЧЕНИЕ(ПланВидовХарактеристик.НастройкиПользователей.ОсновнойВидНоменклатуры))
        И Шапка.Система.ВидНоменклатуры = НастройкиПользователей.Значение

В общем-то концептуально он выполняет ту же самую функцию - ограничение по реквизиту документа, даже в моем случае по реквизиту реквизита.
Чем конструкция

1 В
                (ВЫБРАТЬ ПЕРВЫЕ 1
                    1
                ИЗ
                    РегистрСведений.ПраваДоступаПользователейКОбъектам КАК ПраваДоступаПользователейКОбъектам
                ГДЕ
                    ПраваДоступаПользователейКОбъектам.ОбъектДоступа = АктОбОказанииПроизводственныхУслуг.Контрагент
                    И ПраваДоступаПользователейКОбъектам.ОбластьДанных = ЗНАЧЕНИЕ(Перечисление.ОбластиДанныхОграниченияПравДоступа.КонтрагентыДанные)
                    И ПраваДоступаПользователейКОбъектам.Пользователь В (&ГруппыТекущегоПользователя)
                    И ПраваДоступаПользователейКОбъектам.Чтение = ИСТИНА))

лучше использования Внутреннего соединения?
Может быть это влияет на быстродействие и мне тоже лучше использовать условие ГДЕ ?

Мне кажется ваша конструкция не будет работать медленнее

интересно , конечно, узнать в цифрах сравнительное быстродействие для разных конструкций запросов.

Первый вариант использует одну таблицу и сложное условие с вложенным запросом
Второй вариант две связанные таблицы.

Но вопрос, оказывается, ещё и в том, что эти варианты не равнозначны в функционале.
Для второго варианта у меня не получилось реализовать ограничение по двум реквизитам через ИЛИ

То есть, когда мне понадобилось добавить ещё права и на документы с Ответственный = Пользователь, то пришлось использовать типовую конструкцию с одной таблицей

ЗаказПокупателя.Ответственный = &ТекущийПользователь
    ИЛИ 1 В
        (ВЫБРАТЬ ПЕРВЫЕ 1
            1
        ИЗ
            РегистрСведений.НастройкиПользователей КАК НастройкиПользователей
        ГДЕ
(НастройкиПользователей.Пользователь = &ТекущийПользователь)
        И (НастройкиПользователей.Настройка = ЗНАЧЕНИЕ(ПланВидовХарактеристик.НастройкиПользователей.ОсновнойВидНоменклатуры))
        И ЗаказПокупателя.Система.ВидНоменклатуры = НастройкиПользователей.Значение

Правда я так и не осознала до конца как работает 1 В
(ВЫБРАТЬ ПЕРВЫЕ 1
1
Никогда бы не придумала составить такое условие, если бы не подглядела в типовой... Однако штучка эта рабочая, результат получился тот, что мне нужен.

И всё таки остается вопрос быстродействия . Как оптимизировать такие запросы? На маленьких списках этот вопрос не возникает, но с ростом базы работа со списком документов существенно замедляется... Особенно , если подключать связанные списки с отборами по основному

RLS + запросы такого типа зло ... Юзайте попроще ...
ЗЫ: конструкция с единицей будет работать быстрее так как результат не будет содержать объект ссылочного типа ...

Спасибо, за ответ по быстродействию.
Можно ещё пример для моей ситуации , как решить попроще?
Нужно дать доступ на чтение и просмотр пользователю только тех Заказов покупателя , которые он внес сам или которые относятся к тем Системам, что ему доступны. Система - реквизит документа Заказ покупателя

Заведите реквизит Создатель, в РЛС напишите Где Создатель = &глПользователь Или Система = &глСистема
глСистема и глПользователь - глобальные переменные.
ЗЫ: повторюсь не мудрите с РЛС ...

Насколько запрос

ЗаказПокупателя.Ответственный = &ТекущийПользователь
    ИЛИ 
ЗаказПокупателя.Система = &глСистема

работает быстрее , чем этот

ЗаказПокупателя.Ответственный = &ТекущийПользователь
    ИЛИ 1 В
        (ВЫБРАТЬ ПЕРВЫЕ 1
            1
        ИЗ
            РегистрСведений.НастройкиПользователей КАК НастройкиПользователей
        ГДЕ
(НастройкиПользователей.Пользователь = &ТекущийПользователь)
        И (НастройкиПользователей.Настройка = ЗНАЧЕНИЕ(ПланВидовХарактеристик.НастройкиПользователей.ОсновнойВидНоменклатуры))
        И ЗаказПокупателя.Система.ВидНоменклатуры = НастройкиПользователей.Значение

? Если бы были какие -то сравнительные цифры по быстродействию( например , открытие списка из 20 000 документов у пользователя с такими ограничениями в первом и во втором случае), то было бы интересно их узнать.
И за счет чего получится быстродействие?
Иначе имеет ли смысл при необходимости ввода ограничений по разным полям, каждый раз заводить новые глобальные переменные? Я за то, чтобы поменьше программировать. И в том , и в том случая РЛС придется настраивать, но во втором ещё прописывать код в модулях.

Я бы сказал что в разы ... Но при условии, что чем старше версия MS SQL тем лучше отрабатывает оптимизатор запросов - то разница будет ощутима только на больших объемах ... Плюс кэширование запроса - первый раз он выполниться в 100 раз медленнее чем последующие ...
ЗЫ: сказать в реальных цифрах нет возможности ... Нужно экспериментировать ...
ЗЫЫ: профайлер в руки + необходимо зарегистрироваться для просмотра ссылки и любой запрос в ваших руках будет работать очень быстро

Это всё хорошо для MS SQL. А если файловый вариант?
Есть какие-нибудь статьи-исследования по сравнению быстродействия выполнения одного и того же RLS запроса в файловом и SQL варианте базы?