Прежде всего, я очень сожалею о том, как долго этот вопрос и ценим ваше время на его чтение!
В настоящее время мы разрабатываем то, что я предпочитаю описывать как веб-платформу, которая содержит несколько приложений и столкнулась с проблемой разрешений.Это внутреннее приложение для нашего бизнеса, которое не является общедоступным, поэтому у нас есть уникальные потребности.
Мы не можем использовать строгую систему разрешений на основе групп, потому что она слишком общая, что делает ее слишком строгой, некоторым сотрудникам потребуется доступ к нескольким приложениям, нескольким отделам (некоторые могут называть их группами) в приложениях и только несколькимфункции в каждом отделе.
Нам также необходимо иметь возможность отображать данные динамически, так как мы разрабатываем ряд приложений для платформы, нам необходимо иметь возможность регистрировать информацию в базе данных, затем она заполняет соответствующие флажки и проверяетих, если у пользователя есть доступ, или оставьте их пустыми, если у пользователя нет доступа к приложению, отделу или функции.
По этим причинам нам необходимы трехуровневые разрешения, которые состоят из
- приложений, к которым пользователь может получить доступ
- отделов, к которым пользователь может получить доступ
- конкретные функции, к которым пользователь имеет доступ
Теоретически это должно быть очень просто, я уверен, что на самом деле лучшее решение будет довольно простым, но я думаю, что мы либо что-то упускаем, либослишком пристально присматриваясь к чему-либо.
Прежде чем идти дальше , я понимаю, что существует несколько способов справиться с этой ситуацией в ее существующей структуре, у нас 6 работает и работает правильнооднако они используют «необычные» методы, и нам действительно нужно лучшее решение, и я считаю, что это начинается с проектирования базы данных.
В настоящее время мы опробовали системы с тремя таблицами, которые имеют следующие таблицы, относящиеся к разрешениям
Регистр приложений: содержит список всех приложений на платформе
app_id (primary AI) | perm_id (int) | app_name | app_code | app_location | tab_location | access_key
Регистр разрешений для приложений: содержит список всех разрешений для каждого приложения, независимо от того, является ли оно приложением, отделом или функцией (определено в access_type ниже)
permission_id (primary AI) | perm_id (int) | app_id | permission_code | permission_name | permission_description | access_type
Определенные пользовательские разрешения: это содержит определенные разрешения, которые относятся к приложению, отделу и функции
permission_id (primary AI) | perm_id (varchar) | app_permission_id | app_id | user_id | access_status | function_code
Проблема возникает с назначением разрешений, как когда мы приступаем кНа уровне функций мы обнаружили, что запрос mySQL должен быть слишком конкретным для получения информации о доступе пользователя, и мы не можем получить полный список функций для этого отдела, значения NULL не возвращаются в LEFT JOIN, гдеони должны - это относится к определенному полю, которое имеет общее имя в нескольких таBles объединяются, но разные данные в каждом.Мы указываем все поля, которые мы хотим вернуть из каждого запроса, но по какой-то причине это 1 поле продолжает появляться, и неправильные данные объединяются.
Итак, я думаю о реализации следующей структуры:
Регистр приложений: для хранения списка всех приложений с URI и ссылкой на систему навигации
app_id (primary AI) | app_name | app_uri | app_tab
Регистр отдела: для хранения списка всех отделов и связи с приложением
dept_id (primary AI) | app_id | dept_name
Регистр функций: для хранения спискавсех функций и отношений с отделом, отдел в «реестре отделов» относится к приложению
function_id (primary AI) | dept_id | function_name | function_description
Конкретные разрешения пользователя: для хранения списка всех функций пользователяможет выполнять, это связано с регистром функций, который связан с регистром отдела, который связан с регистром приложения
permission_id (primary AI) | user_id (index) | function_id | permission_status (int - 0 = not allowed access | 1 = allowed access)
РЕДАКТИРОВАНИЕ СТАРТ
Я только что понял, что что-то не совсем верно в конкретной таблице разрешений пользователей, как показано выше, я не учитываю разрешения приложений или отделов, так как это выглядит?
Я изменилсяОт function_id до permit_item для хранения идентификатора элемента, затем добавленного в permit_type, чтобы определить, является ли это приложение, отдел или функция, к которым пользователь имеет доступ.
permission_id (primary AI) | user_id (index) | permit_item | permit_type | permission_status (int - 0 = not allowed access | 1 = allowed access)
EDIT END
Отсюда мы можем, например, выполнить несколько соединений в запросе (я понимаю, что только для того, чтобы показать концепцию только в целях иллюстрации, я понимаю,что это не правильный запрос или лучший способ написать его в рабочей среде)
SELECT * FROM app_register
JOIN dept_register ON app.register.app_id=dept_register.app_id
JOIN function_register ON dept_register.dept_id=function_register.dept_id
JOIN user_permissions ON app_register.app_id=user_permissions.app_id
WHERE user_permissions.user_id='1'
Это должно дать мне упрощенную объединенную таблицу разрешений, которая связывает все функции, отделы и приложения, а затем перечисляет, какие приложения пользовательимеет доступ к.
Но мне нужен вклад беспристрастных наблюдателей, а не эмоционально вложенных дизайнеров баз данных и его друзей.
Есть ли что-то, на что я упустил из виду или на что слишком усердно смотрел?
Есть ли еще одна лучшая структура, которую мы можем попробовать, чтобы вы могли обработать эти данные?
Я очень признателен всем за помощь и еще раз извиняюсь за длину этого вопроса!