Всем доброго самочувствия.
Заранее прошу извинить за многословие и наличие "абстрактной шелухи", прошу сильно не пинать.

Ситуация, с которой наверняка сталкивалось множество из присутствующих здесь спецов:
1) есть пользователи с достаточно чёткими должностными ограничениями на просмотр/изменение чего-нить; пользователи, как правило, объединены понятием "ДОЛЖНОСТЬ" ("подразделение", "роль");
2) есть некие сущности, с которыми работают эти пользователи (например, изделия склада, контрагенты (покупатели/поставщики/сотрудники), деньги, трудозатраты, ...)
3) есть атрибуты сущностей (названия, артикулы, цены закупочные и розничные для изделий; реквизиты для контрагентов, и т.д и т.п.)
4) есть операции над сущностями (ИЗМЕНЕНИЕ цены розничной или места хранения какого-либо изделия; ОТГРУЗКА товара со склада и перевод документа в разряд недоступных для дальнейших изменений; ОБЪЕДИНЕНИЕ балансов двух контрагентов; много еще чего).

Программная система должна предоставлять для некоторого пользователя какой-то конкретной должности при работе над "сущностью" какого-то конкретного вида РОВНО столько информации (возможностей), сколько:
(
  1) ему положено по должностным обязанностям этого бизнес-процесса;
 {OR}
  2) ему ДОПОЛНИТЕЛЬНО РАЗРЕШЕНО "за то, что умный"
)
AND
3) он НЕ находится в списке тех, кому ЗАПРЕЩЕНО "за то, что глупый"
AND
4) может быть представлено атрибутами "сущности", с которой он сейчас работает (напр., для "Контрагента" не может быть понятия "Место хранения" (если это не вытрезвитель, конечно :))
{AND}
3) допустимо в текущем СОСТОЯНИИ сущности (напр., в документе склада со статусом "Отгружен" нельзя менять никаких данных, касающихся его содержимого; однако можно менять данные, касающиеся его оплаты)
{AND}
4) допустимо (сейчас) с точки зрения... администратора БД(!) Потому что иногда ОЧЕНЬ надо, чтобы база была доступна всем, но только на ЧТЕНИЕ.
{AND}
5) еще чего-нибудь, что знаете Вы лично.

Возможности пользователя выражаются в наборах операций, которые он видит (например, в виде PullDown-меню, панелей инструментов etc).
А информация, чаще всего, представлена в виде таблиц ("гридов", "вьюх", кому как нравится) с теми столбцами, которые он, юзверь ЭТОЙ ДОЛЖНОСТИ, имеет право смотреть.

Для меня совершенно очевидно, что все эти "менюхи да вьюхи" должны жить в БД. Может, это спорный взгляд, но когда у тебя 10 должностей с ОЧЕНЬ разными обязанностями и правами (уровнем допуска) и 15 разных видов документов (и очень многие -- с разными наборами состояний, которые надо автом. отслеживать и отображать), то я не представляю, как это всё хранить "на клиенте".

Но тогда для записи всех возможных вариантов этих "менюх+вьюх" потребуется "ну очень" много дней и, возм., ночей, т.к. встаёт зловещая тень "декартова произведения" справочников "Должности", "Виды состояний сущностей", "Атрибуты сущностей" и "Операции над сущностями".

В голове периодически возникают мутные мысли о наследовании, но не более того (да и какое наследование можно сделать с помощью таблиц?)

Догадываюсь, что народ как-то решает эту задачу. Как ?

Всем ответившим заранее спасибо.

ModelR
Возьмите какую-нибудь реальную систему и посмотрите

Дык реальная система у меня есть, я её сам сбацал несколько лет назад и она успешно крутится на достаточно большом предприятии.
Только вопрос о реализации "менюх+вьюх" для всех ячеек пересечения множеств (должностей/видов документов/состояний/...) решён был просто топорно, "в тупую": на каждую такую "ячейку" в БД создавались отдельные строки и всё описывалось "с нуля". Не бейте только, господа: времени на обдумывание просто не было, надо было делать ОЧЕНЬ быстро.
Соотв-но, и повторов получилось неимоверное число, один и тот же код (синтаксис вызовов, описания, текстовые строки) хранится в десятках (сотнях!) строк. И хотя обновлять что-то в этой куче достаточно просто (это же таблицы, а не исходники!), всё равно не покидает ощущение, что "что-то не так". Можно было бы, уверен на 1000%, сделать поизящнее.

Shtock
у меня система СКД (контроля доступа) состоит из 60 таблиц.

2Shtock: Можно узнать, почему так много ?
2LSV: про роли (или "должности") всё понятно, так делают, наверное, в 99% систем.
Но что делать, когда несколько ролей по производственной необходимости должны работать с одними и теми же пресловутыми "сущностями" (документами определённых видов, контрагентами, курсами-валютами и проч.), причём каждой роли можно давать далеко не весь набор операций и показывать эту "сущность" не всю, а только некоторые атрибуты ? Тогда запросы к административной части БД для получения прав, списка возможностей и др. будут усложняться. Но главное, что ЧИСЛО запросов на все эти вариации бизнес-процесса будет большим (мягко сказать!).

Поясню свой вопрос двумя простыми ситуациями:

1) Добавление всего одного вида документа (скажем, появится какой-нибудь новый вид поступления изделий -- "Оприходование товара на условиях консигнации") -- так вот, появления новой строки в справочнике "Вид документов" повлечет за собой добавление десятков строк, описывающих то, какие возможны операции с ним для разных ролей и разных состояний этого вида документа. А также появятся десятки строк с описанием того, как должно выглядеть СОДЕРЖИМОЕ этого документа для разных подразделений (то бишь "вьюхи").

2) Добавление всего одной РОЛИ (например, "Менеджер работе с корпоративными клиентами") также влечёт за собой необходимость описания того, к каким видам документов (или других "сущностей") его допускать, ЧТО он там может видеть и что имеет право делать.

Я спрашиваю как раз про это: есть у кого-нибудь идеи на тему, как уменьшить объём работы по описанию всех этих менюшек, вьюшек и прочей мути в такий случаях ?

guest_20040621
Есть четыре уровня метамоделей. Выберите уровень... - все сразу станет сильно проще.
Собственно контроль доступа - простая задача; три основных подхода: ACL, rwe и их комбинация.


guest_20040621, можно Вас попросить какую-нибудь ссылку на темы уровней метамоделей, ACL, RWE etc (или название книги/статьи) ? А то в поисковиках слишком много всего вытряхивается на эту тему, просто "в лом" всё это перелопачивать. Буду весьма признателен, если укажете, куда копать надо.

guest_20040621
Повторюсь: есть четыре уровня метамоделей. Важно четко представлять себе каждый из этих уровней для того, чтобы не ограничивать функционал приложения.

guest_20040621, уж простите за назойливость, но тогда и я повторюсь: какие это "уровни метамоделей", как они зовутся, что обозначают, ГДЕ ПРО НИХ ПОЧИТАТЬ ?
ЗЫ. Никакой подоплёки, никакого сарказма в моём вопросе нет: я просто хочу получить новые знания по этой теме.