Задача:
Есть документ, назовем его "Документ". У него есть две табличные части "ТЧасть1" и "ТЧасть2". Пользователь должен видеть Документ в том случае если: а. "ТЧасть1" содержит элемент удолетворяющий некому критерию б. "ТЧасть1" пустая и "ТЧасть2" содержит элементы удолетворяющие некому критерию. Сложность вычисления критериев - равная.
Методы решения:
1. Сотворить 1 сложный RLS запрос с объединением, в одной части которого проверяется а, во втором б.
2. Сделать две роли с мелкими запросами без объединения и дать пользователю обе.

Как думаете что будет работать быстрее )

P.S. ничего не курил, а вот похмелье да.. присутствует.

(0) RLS будет работать всегда медленно.

3. Сделать в документа реквизит "ПоказыватьПользователю", заполнять его в ПередЗаписью и ниипать мозк

(2) Нееее... зае..сь создавать реквизиты под каждого юзера.

(3) Как бэ в реквизит не обязательно булево.

(1) да вы батенька пессимист

(4) Не решает той проблемы, если область видимости пользователя поменялась после записи объектов.

у меня есть такое решение RLS (для сложных условий), реально работает вполне быстро

1. в документе делается реквизит ХЕШ (справочник)
2. делается РС с измерениями Пользватель, Хеш
3. в справочнике хеш есть ТЧ в которой лежать все критические поля которые дают искомую комбинацию открывающий доступ
4. при записи документа из самого документа ищем все критические поля и по ним ищем элемент справочника хеш (или создаем) и записываем в реквизит документа.


в моем случае критерием доступа было 4 элемента разных справочников, но когда разрабатывал считал комбинаторику при 1000 пользователей можно использовать хешь до 10 разных полей

(5) Нет, я увы реалист. Пока база маленькая все просто летает, но когда вырастает размер в разы, начинаются отчеты, отборы и т.д.
"-А что тогда происходит? А наступает счастье!" ((с) Е.Гришковец)

(8) ты самого главного не понял, автор выбирает между одним большим RLS и двумя более простыми.

в обоих случаях RLS будет :)

(7) Тоже обдумывал нечто подобное. Надо будет проработать.