> Так и есть. Причем если самих объектов, на которые раздаются права
> "считанные миллионы", то связанных будут десятки миллионов.

Вот с этого места, пожалуйста, поподробнее. Есть некоторое количество объектов (O1, O2... On), включающих атрибуты (A1, A2... An), которые связаны с объектами (RO1, RO2... ROn), включающих атрибуты (...). Пусть изменились права доступа к объекту O1 (было RA1, стало RA2). Вопрос: как должны меняться права атрибутов (A1.. An) и связанных объектов (RO1... ROn) с их атрибутами? Если я правильно понимаю, связи - не уникальные? Т. е., нет гарантии, что с объектом RO2 связан только объект O2, а может быть связан и O1? А если меняются оба объекта (O1 и O2), отрабатываются все связи последовательно?

> Но доступы есть и ролевые, когда права на объекты даются приложению, и
> личные. Сейчас разговор только о личных. Хотя ролевые хранятся так же, но
> владельцы у них не пользователи.

Понятно. Я немного не то имел в виду. Если не всем и не всегда нужно проверять права доступа (например, некоторая часть пользователей не изменяет объекты, а только читает их), оправданно завести для этого признак, вне контекста прав. Флаг установлен - права не проверяются.

Для ограничения доступа обязательно использовать права или можно обойтись более простым понятием (уровень доступа)? Другими словами, доступ всегда обязательно связан с изменениями объектов базы данных?

> Вопрос в эффективных правах кучи пользователей на кучи объектов при
> массированной нагрузке.

А пользователей и объекты никак нельзя сгруппировать по каким-нибудь признакам? Т. е., перейти от персональных политик к групповым?

> Физически объект - одна таблица, классификаторы - ссылки типа

Ну, это уже хорошо. Хуже было бы при множественной классификации. ;)

> Особенно, когда вечером меняли, а утром 1000 пользователей ломанулась инфу
> смотреть.

А какая вообще периодичность и частота изменений? А если так: есть процесс, который занимается тем, что вносит изменения (т. е., полагаем, что связи формализованы, объекты бд описаны и пр.). И количество запущенных процессов связано с а) временем суток, б) приоритетом задачи, в) количеством изменений, г) нагрузкой на приложение (...). Т. е., по сути это daemon, внешнее приложение (например, на C, чтобы быстрее; можно со своим методом доступа), которое всегда работает, просто с разной интенсивностью.

> Есть такое. Объект помечен специальным образом. Пометок может быть две.
> "Доступен всем" и "Недоступен всем".

Не, я не об этом. Понятия прав imho целесообразно использовать при _изменении_ объектов. А если нужно просто ограничить доступ, я бы разбил и объекты, и пользователей на категории (одни и те же). И показывал бы те объекты, числовой эквивалент которых (не id) меньше или равен (например) числовому идентификатору пользователя. Без затей. А вот если менять объекты, тогда проверка прав по полной схеме. Т. е., описывал бы одинаковым образом и пользователей, и объекты.

> Где можно обойтись "категорией" - обходимся. Некоторые категории как раз и
> дают пользователю доступ ко всему.

Не, я снова не об этом. Права доступа - для _изменения_ объектов. Только. Уровень (категория) - для _ограничения_ доступа. Т. е., все объекты - read only, сравнивается только числовой эквивалент.

>> Хуже было бы при множественной классификации. ;)
> А есть разница?

Конечно. Затратнее.

> То есть таки хранить?

Ага.

> И хранить именно в виде ACL?

А чем хуже атрибуты объектов?

> И - "скрипт" на изменение

Ну, скриптом я бы его уже не назвал. Приложение. С конфигом, логом и пр.

> Кстати, если есть понятие "сессия", то сессионные права - не самый худший
> вариант...

Хм... а речь разве не о них?

> мы все еще думаем, что такое "сессия"

Время с момента авторизации до момента logout?

> А в пределе способ сводится к простому хранению расчитанных прав пообъектно
> с контролем актуальности и пересчетом по мере обращения в случае утери
> актуальности.

Вот-вот. И мне лично непонятно, чем Вам так нравится ACL. Кроме того, мне непонятно, почему процессы у Вас описаны ролями. Imho, это обычные пользователи, которым (возможно) разрешен мультиплицированный доступ (т. е., одновременный логин нескольких пользователей с одинаковыми параметрами). Если непременно нужно знать, что это автомат, проще завести соответствующий признак. А освободившиеся роли использовать по назначению. Ну, не верю я, что задача не решается группировкой пользователей (группы и роли) и описанием прав групп, ролей, владельцев и прочих.

Дружище member Crimean, пожалуйста, читайте внимательнее. Приводите цитату в контексте.

Речь шла о том, что применять ACL можно для регистрации _исключений_. _Если такая необходимость [imho абсолютно теоретическая] есть_. А не строить политику доступа на ACL. Разница, надеюсь, понятна.

> т.е. ACL это Вам указали в самом начале.

Пожалуйста, возьмите калькулятор и умножьте 1000 пользователей на 1000000 объектов (по условиям задачи). А теперь умножьте это на 10 миллисекунд (очень оптимистично). Вы получите время, потраченное на заполнение ACL таблицы. Если при этом Вы все еще считаете ACL хорошим решением, - дискуссия imho смысла не имеет.