Это крен в сторону RBAC - контроль доступа на основе ролей. Вы также можете спросить, использовать ли LBAC - контроль доступа на основе меток. И, в зависимости от вашей СУБД, могут быть и другие способы достижения этого (например, рассмотрим Oracle VPD - виртуальную частную базу данных). Все это скорее или очень специфично для СУБД - разные решения для разных СУБД.
Кажется, вы говорите об управлении на уровне строк. То есть одна строка в таблице контактов может быть доступна каждому, а другая - только одному набору отделов, другая - только одной группе людей и т. Д.
Помните, что реляционные СУБД лучше всего работают с наборами. Одна группа - это набор групп с одной группой участников; один пользователь - это набор групп с одним пользователем. Это означает, что у нас меньше дел для рассмотрения.
Если вы хотите реализовать его в стандартном SQL, то я думаю, что вам нужно будет использовать комбинацию представлений, использующих соединения с управляющими таблицами и т. Д. Сложные части такой системы - заполнение управляющих таблиц и ограничение административные пользователи (на самом деле ограничение администраторов - это всегда одна из трудных частей).
Основная техника будет:
- Создайте базовую таблицу с соответствующим столбцом для определения набора привилегий, который применяется к каждой строке в таблице.
- Отменить все общедоступный доступ к таблице.
- Создает представление на базовой таблице, которое показывает все столбцы из базовой таблицы, которые разрешены. Это будет представление соединения с управляющей таблицей, которое будет определено на мгновение. Условия запроса просмотра также будут обусловлены текущим пользователем.
- Предоставить соответствующий доступ к представлению.
- Создать соответствующие триггеры INSTEAD OF в представлении для обработки операций вставки, удаления и обновления в представлении, передавая изменения в базовую таблицу.
- Создайте управляющую таблицу для объединения с базовой таблицей.
- Заполните его соответствующими данными.
- Светло-голубая сенсорная бумага и хорошо отстает.
Теперь об этом соединяющем столбце и управляющей таблице ...
Кто-то должен указать, какие разрешения применяются к вновь вставленным строкам в таблице - какой доступ предоставляется по умолчанию. И кто-то должен определить, как доступ по умолчанию может быть отменен. Оба из них могут быть грязными.
Существует несколько способов структурировать управляющую таблицу:
Один механизм опирается на каждую строку в базовой таблице, имеющую уникальный идентификатор (который может быть автоматически сгенерированным идентификатором или только значением первичного ключа). Затем контрольная таблица включает в себя копию этого уникального идентификатора и определяет, какие пользователи или группы могут получить к ней доступ. Это означает, что может быть несколько записей в управляющей таблице для данной строки, по одной для каждого пользователя или группы, которые могут получить доступ к строке. В этой схеме управляющая таблица имеет внешний ключ, который ссылается на базовую таблицу.
Другой механизм внедряет идентификационный номер в базовую таблицу, который является внешним ключом для управляющей таблицы. Он в основном идентифицирует набор привилегий, а ссылка в базовой таблице означает, что строка имеет разрешение доступа, связанное с идентификатором управления доступом. Структура за управляющей таблицей может заключаться в том, что идентификатор 0 не имеет доступа для кого-либо (через представление), идентификатор 1 имеет доступ для всех, а другие значения обозначают комбинации пользователей и групп - каждая отдельная комбинация имеет различный идентификатор. При этом в наборе управляющих таблиц может быть несколько таблиц, и мы также обсуждаем наличие набора этих управляющих таблиц для каждой защищенной таблицы.
Очевидно, что доступ к контрольным таблицам строго ограничен, но также важен для управления тем, кто может что видеть.
Обе эти проблемы - административные ночные кошмары, поэтому вам, скорее всего, придется использовать механизм контроля доступа, предоставляемый СУБД, а не универсальное решение SQL.