С ростом числа пользователей и усложнения системы раздачи прав я все больше склоняюсь к мысли, что права пользователей на объекты надо хранить в расчитанном виде. Ну или в предрасчитанном, если будет угодно. Попробую пояснить. Есть база пользователей. Скажем так, пока до 1000 , но уже больше 100. Есть объекты, типов которых с десяток. Есть права на объекты. Права разные для объектов разных типов, но прав до десятка на каждый тип объекта. Просто некоторые права для некоторых типов объектов (пока) не востребованы. До сих пор каждое обращение к объекту происходит через перерасчет прав пользователя на этот объект.
Да! Оч важен факт, что сама система прав достаточно сложная, с возможностью делать исключения. Типа можно читать все каталоги диска кроме каталогов, начинающихся на 'S%' ну или в этом духе. То есть агрегация в правах УЖЕ присутствует.
Система раздачи (и хранения розданных прав) по возможности упрощена в целях хоть как-то в этом безобразии разобраться. Естественно, ролевая модель, то есть есть роли, права даются им, а для пользователя права ролей суммируются. Вопрос не в этом, все это описание приведено только для понимания сути проиисходящего и носит сугубо приблизительный характер.
Вопрос в том, а не хранить ли уже готовые права в отдельных таблицах? Точечные запросы, конечно, много не едят, но их очень много. И когда их очень много, то даже 16 ms на запрос уже чуствительно. Но как только мы начинаем хранить уже расчитанные права пользователей на объекты в виде Ид пользователя + Тип объекта + Ид объекта + Ид права + Состосние права (или в немного денормализованном виде, по таблице на объект, Ид объекта, Ид пользователя, Право1, Право2, Право3 и т.д.) так сразу возникает вопрос - а что с этим великолепием делать при изменении, пусть несущественном, прав? Пересчет, по предварительным прикидкам, стоит недешево. Более того, одномоментный пересчет прав для всех пользователей для всех объектов стоит ОЧЕНЬ дорого! Из-за того, что при миллионе объектов и 1000 пользователей и 10 правах это будет... Ага! Именно столько! А объектов больше! Конечно, далеко не все пользователи имеют права на все объекты. И степень перекрытия прав невелика. Но это не уменьшает проблему.
Есть у кого-то опыт работы в этом направлении? Речь, естественно, может идти не о правах на объекты, а о любом сложнорасчитываемом, но постоянновостребованном функционале.

Спасибо, если дочитали :)

P.S.Сейчас способ расчета и хранения + набор флагов актуальности применяется частично и на небольшом наборе прав для пользователя (менее 10% объектов доступно) оправдывает себя - цена перерасчета относительно невелика, а сам перерасчет делается только по одному пользователю по факту обращения пользователя за информацией. Если инфа на момент обращения актуальна, то запрос выполняется сразу. Если неактуальна, то пользователь ждет, пока для него актуализируется инфа по доступу.

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

Еще раз.
Система раздачи / хранения / ... прав не обсуждается. Не в ней дело. В любой системе наступит время, когда пользователей станет очень много. Если пользователей много, то расчет списка доступных объектов для каждого пользователя станет недопустимо накладным.
Например, 1000 объектов (фигня, правда ведь!) для 10 пользователей даст в худшем случае до 10 000 записей. А вот та же 1000 объектов для 1000 пользователей даст до 1000 000 записей. А если прав больше (порядка 10)? Уже чуствительно! А если объектов не 1000 , а миллионы?..
Пусть я упростил метод расчета доступности объекта. Но это все равно будет расчет. И в моменты массированного доступа у меня будет завал по производительности - все сожрет расчет доступов. Не думаю, что кто-то будет спорить с тем, что доступ к данным происходит на порядки чаще, чем изменение прав. Суть предложения сводилась к таки расчету списка доступных объектов, но вот когда это делать?
А если делать это только для одного пользователя (в один момент времени) и только в момент доступа самого этого пользователя к данным и то только после изменения прав этого пользователя? А все изменения прав и добавления объектов просто должны инвалидировать признак актуальности прав пользователей, кого это коснулось или всех - это уже дело десятое. Важен принцип, который, вроде как, можно выстроить на соотношении числа обращений за данными и числа обращений за изменением прав.
В итоге чем реже будут меняться права, тем больше будет выигрышь. А ждать будет не админ, меняя права, а пользователь, обращаясь к данным. И количество пользователей тут на время ожидания не влияет. Сейчас, конечно, мне скажут, что после глобального изменения прав как только все ломанутся за своими данными, так сразу все и подохнет. Ну да. Это есть. Это второй вопрос - что делать в таком случае :) Можно, конечно, запустить потихоньку систему считать права для тех, кто чаще доступается...

Речь не только о правах на SELECT, хотя и о них тоже.

Насчет операционной системы господин guest_20040621 лукавит.
В операционках нет раздачи прав на файлы, содержащие слово "вася" с 5 по 10 позицию... А у нас - есть :( Ну и мне сложно себе представить операциоку с парой десятков миллионов файлов в одном (!) каталоге со сложной нарезкой прав на них при наличии 1000+ конкурентных пользователей, щарящих в этом каталоге. При этом регулярно требуется перерезать права...

Насчет компромиссов - да, есть три категории пользователей. Для одной установлен признак "суперпользователь" и все доступно без проверок / расчетов. Для второй категории права считаются при каждом доступе. Для третьей категории формируется что-то типа того же ACL. При добавлении нового объекта он прописывается всем пользователям, кому доступен и для кого доступ актуален. При измении прав сбрасывается флаг актуальности для тех пользователей, для которых права хранятся и для которых списки доступа все еще актуальны...

Но это все для объектов, которые "редко" добавляются. Для объектов, которые часто добавляются права только считаются... Ну и поскольку объекты часто добавляются, то для них ничего (в смысле прав) не хранится... Но считать чем дальше, тем накладнее...

И сколько будет работать такой скрипт на лимоне файлов и тыще юзеров?

Проблема, скорее всего, в том, что у объекта есть несколько ключевых реквизитов и права необходимо раздавать в разрезе всех этих реквизитов.
Или, другими словами, объект типизован несколькими классификаторами. Права пользователям на объект могут быть назначены в разрезе любого или в разрезе нескольких классификаторов. Это, возможно, неправильно, но так надо заказчику. И что с этим делать?