Разработка схемы БД пользователя Роли

Question

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

Вариант 1

Создайте три таблицы, одну с информацией о пользователе, одну с информацией о роли, а другую с отношением роли пользователя.

users {
    u_id,
    etc
}

roles {
   r_id,
   r_name,
   etc
}

user_roles {
   u_idm
   r_id
}

Опция 2

Создание двух таблицодин с информацией о пользователе, а другой с ролью, информацией о роли и информацией о связи.

users {
    u_id,
    etc
}

roles {
   r_id,
   u_id,
   r_name,
   etc
}

Вариант 1 более устойчив, но требует дополнительного объединения.Вариант 2 потребует дополнительного первичного ключа, но будет только одно соединение.Если я когда-либо изменю имя роли, обновление с использованием параметра займет больше времени, но я не ожидаю частых обновлений.

Для масштабируемого решения, что было бы лучше?Какие еще идеи у меня отсутствуют?Это решение для mysql и postgresql.

Answer 1

Вариант 1. Что хорошего в роли, если только один пользователь может иметь каждую роль? Если у вас есть 100 зарегистрированных пользователей, для «зарегистрированного пользователя» будет 100 повторяющихся определений.

Чем больше «и т. Д.», Тем больше будет ваша БД.

Наличие такого количества дубликатов замедлит работу вашей базы данных, и, в конце концов, все будет намного медленнее, даже если у вас меньше одного объединения.

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

Answer 2

Я бы пошел с первым вариантом с некоторыми изменениями:

- each user can belong to ONLY ONE group
- create a table defining privileges
- each group has a list of privileges

Определенные привилегии могут быть привязаны к различным модулям приложения или к определенной функциональности.

Решение простое, гибкое и быстрое.Таблицы как привилегий, так и групп должны быть довольно маленькими, поэтому дополнительные JOIN не окажут такого критического влияния.Кроме того, аутентифицированные пользовательские привилегии могут храниться в сеансе и не загружаться каждый раз.В долгосрочной перспективе будет больше преимуществ, поскольку решение очень гибкое и его легко расширять.

Например, вы создадите новый модуль с именем «Конфигурация» и захотите создать новую группу пользователей с именем «superadmin "иметь доступ везде и" конфигурировать ".Вы просто вносите изменения в базу данных: создаете группу 'superadmin', добавляете привилегию 'config', устанавливаете все привилегии и все.