В настоящее время я разрабатываю администрацию членов для локальной ассоциации, и сейчас я разрабатываю схему базы данных. Я хотел бы поделиться им с вами, чтобы улучшить его и дать другой пример модели доступа на основе ролей (RBAC). Я был бы признателен за конструктивную критику, особенно за отношения, которые я использовал между таблицами.
Ссылка на highres: http://i.stack.imgur.com/WG3Vz.png
Вот схема: 
Как это работает:
Я сопоставляю существующие клиенты (фактически члены ассоциации) из внешнего приложения в свое приложение администрирования. (таблица клиентов)
Ассоциация структурирована в подразделениях, подразделениях и т.д. (таблица intern_structures). Каждый клиент может быть членом в нескольких подразделениях, подразделениях, разделах и т.д.
Каждый клиент может иметь одну или несколько ролей в таких членствах (подразделениях,...), таких как президент, актуарий, казначей и т.д., и каждая роль имеет определенные привилегии, которые владелец этой роли может применить к другим в своем подразделении, подразделении, Раздел и т.д.
Учетные данные связаны с определенным действием приложения. Владелец учетных данных может выполнить это действие на других членах в своем объеме. Могут быть несколько "автономных" приложений, но все они имеют одну и ту же систему авторизации/авторизации.
Приложение структурировано в модулях/субмодулях/действиях и т.д. Примером может быть модуль "Личные данные", и этот модуль содержит подмодуль под названием "Изображение", и вы можете применять действия "просмотр, удаление, редактирование" на этом картина. Но вы не можете удалить любую картинку, если человек, чья фотография, которую вы пытаетесь удалить, находится в разделе/разделе, где у вас есть соответствующая роль.
Внутренняя структура и структура приложения являются деревьями, реализованными как набор вложений и. Список смежности гарантирует целостность, и вложенный набор позволяет мне быстро пересекать дерево.
Исключением является то, что вы можете дать кому-то определенные учетные данные напрямую (client_credentials). Это необходимо, если кто-то должен выполнять определенные действия на тех, кто не находится в разделе divsion/section.
Итак, кто-то может быть членом нескольких разделов/разделов и получать несколько ролей в каждом подразделении/разделе, членом которого он является. Я собираюсь объединить все учетные данные, которые кто-то имеет через его несколько ролей. И учетные данные всегда положительные, означает, что ограничительные учетные данные невозможны.
