Модель базы данных пользователей и групп - PullRequest
3 голосов
/ 18 февраля 2011

У меня есть 2 объекта: пользователи и группы. Самая простая модель - это пользователь (id, имя и т. Д.), Группа (id, имя), user_group_rel (user_id, group_id). Но мне нужно включить группы в другие группы. Один пользователь может быть во многих группах, и группы могут включать пользователей и подгруппы с собственными пользователями и подгруппами! Нужна помощь с моделью базы данных!

Users and groups

Ответы [ 4 ]

4 голосов
/ 18 февраля 2011

Хотя я согласен с номенклатурой Кена Дауна, я не обязательно согласен с тем, что пользователи и роли - это одно и то же лицо.

Базовые объекты:

Users     (user_id, user name, real name, user_status, etc)
Role      (role_id, role name, role_password, etc)
Privilege (priv_id, base object, functionality, what have you)

Ассоциативные объекты:

User has Role (0 - n) (user_id, role_id)
Role has Role (0 - n) (role_id, has_role_id)
User has Privilege (0 - n) (user_id, priv_id)
Role has Privilege (0 - n) (role_id, priv_id)
3 голосов
/ 18 февраля 2011

В наши дни это делается путем объединения пользователей и групп в «роли».Все, что у вас есть, - это роли и связывание ролей с другими ролями.Для некоторых ролей установлен флаг true для входа в систему, что делает их действительными пользователями, в то время как роли, для которых не установлен флаг входа в систему, больше похожи на группы.

Основная идея заключается в том, что все становится проще.Вам не нужно поддерживать две отдельные концепции или сущности (пользователь и группа), а только одну концепцию: роль.Затем вы используете этот флаг «login» для пользователей.

EDIT : Для структуры таблицы посмотрите на первый параметр, предоставленный @XIVSolutions, он объясняет то, что я упоминал выше.Он отвечает на ваш вопрос о размещении одной роли в любом количестве других ролей.Вторая таблица, перекрестная ссылка, перечисляет роль и ее родителя.Если у роли есть несколько родителей, то есть несколько записей в этой таблице, это похоже на наличие одного пользователя во многих группах.

# DIT : Также повторяйте: @XIVSolutions дизайн таблицы, эта третья таблица является совершенно законным способом иметь пользователей (логины) в качестве отдельно управляемых объектов.

2 голосов
/ 19 февраля 2011

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

create table groupmemberbase
(
  memberid int,
--optional flag to idicate the type of the derived entity
--this is similar to the login flag used by Ken Downs 
  membertype int,
  primary key (memberid)
)

create table users
{
  memberid int,
--more user attributes here
  primary key (memberid),
  foreign key (memberid) references groupmemberbase (memberid)
)

create table groups
(
  memberid int,
--more group attributes here
  primary key (memberid),
  foreign key (memberid) references groupmemberbase (memberid)
)

create table groupmembers
(
  groupid int,
  memberid int,
  primary key (groupid, memberid),
  foreign key (groupid) references groups (memberid)
  foreign key (memberid) references groupmemberbase (memberid)
)

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

2 голосов
/ 19 февраля 2011

re: решение Ken Downs:

Я играл с двумя версиями этого (и ЛЮБЛЮ слышать, если это на цели или нет ...):

Вариант 1:

**tblRole**
RoleID PK
RoleName

**tblRoleIndex**
ParentRoleID FK on tblRole  
ChildRoleID FK ON tblRole

NOTE: ParentRoleID and ChildRoleID form a composite Primary key in the above table.

**tblLogIns**
LogInID PK
RoleID
PassWord

Или, вариант 2:

**tblRole**
RoleID
ParentRoleID Recursive FK on tblRole.RoleID
RoleName

NOTE: A top-level role in the table above has a default ParentRoleID of -1 or 0

**tblLogIns**
LogInID PK
RoleID
PassWord
...