Данная заметка появилась благодаря обсуждению темы
Бизнес логика в хранимых процедурах...

emchenko попросил меня рассказать о моем варианте распределения прав на объекты базы данных, что и делаю. Все замечания, дополнения, новые идеи будут приняты с благодарностью.

Задачу, которую я себе поставил, можно сформулировать так
"Большая часть таблиц содержит в себе сущности, над которыми пользователь может совершать определенные действия. Надо сделать такой механизм, который позволит единообразно выдавать права совершать различные действия над экземплярами сущностей для каждого пользователя"

Таким образом у меня получилась такая структура

(таблица 1)

- Пользователь
- Тип сущности (фактически номер таблицы)
- ID сущности (ID в таблице)
- права на совершение действий (флаги)

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

Так появились две вспомогательные таблицы

Первая содержала в себе список сущностей, к которым я хотел бы организовать допуск
- ID типа
- Наименование типа

Вторая содержала набор действий по отношению к этой сущности
- ID типа
- Номер бита (1..32)
- Расшифровка (что за операция может быть доступна по отношению к сущности, если этот бит установлен)

Теперь я имел уже достаточно IMHO удобную структуру – в хранимой процедуре я мог проверить по ID пользователя, типу сущности и ID сущности и какие действия данный пользователь может производить с конкретной сущностью по набору флагов.
Эту проверку можно сделать в хранимой процедуре перед выполнением каких-либо действий и либо отказать, либо разрешить эти действия.

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

Но если количество пользователей превышает 100, то выдавать права каждому – это неудобно.

И решено было реализовать идею групп. Я ее сделал более широким образом – ввел три уровня:
1. Пользователь
2. Должность – каждая фирма имеет список должностей и само собой какие-то права. Включает в себя пользователей. Вообще это нормально, когда в фирме каждый пользователь имеет какую-то должность. Или даже несколько
3. Группа – может включать в себя как отдельного пользователя, так и должность. Например топ-менеджеры, бухгалтерия, финансовый отдел.

Я на тот момент не смог сделать так, чтобы получать побитовое сложение одним запросом и потому все такие права хранил в отдельных таблицах для пользователей, должностей и групп наподобие таблицы 1 и по команде делал пересчет, который каждому пользователю определял права учитывая индивидуальные права, должностные и групповые. Результат записывался в таблицу 1. И по этой таблице производится проверка прав.

Таким образом если пользователь вызвал процедуру для совершения действия над какой-либо сущностью мне остается только взять ID пользователя, ID сущности и вытащит права пользователя по отношению к данной сущности. Накладывая битовую маску, которая по сути является числом, определяющим номер действия над сущностью, получим ЗЯ или НИЗЯ

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

Также готов ответить на вопросы.