Как моделировать отношения «несколько ко многим» в базе данных?

Question

Это не совсем отношения «многие ко многим». Например: У меня есть таблица пользователей и таблица ролей. Ограничение: пользователь может иметь 0-5 ролей, а роль может быть назначена для многих пользователей.

Как смоделировать это в базе данных? Спасибо

EDIT: Я ищу стандартное решение на стороне базы данных для этой модели. Существуют аналогичные сценарии, подобные описанным выше. Например: история паролей пользователей: У одного пользователя будет максимально 10 предыдущих паролей, хранящихся в таблице pwd_history. Это своего рода отношение к одному (0-10).

Но, похоже, стандартного решения на стороне базы данных нет. (Решение @ Branko (2) ниже выглядит неплохо.) Я думаю, что лучшей практикой для этой модели является обеспечение соблюдения на стороне клиента, что делает эти номера настраиваемыми в файле свойств и реализующими клиентскую логику для обработки этого.

Answer 1

Создать таблицу UserRoles

UserRoleID PK 
UserID  FK 
RoleID  FK 

Вы должны следить за соблюдением 5 ролей ограничение с триггером INSERT (пример here), или в бизнес-логики приложения.

Answer 2

Возможно, это не нормализованный дизайн, но для небольшого количества ролей вы можете просто добавить 5 столбцов с нулевым значением для пользователя, role1, role2 и т. Д., Хотя это может усложнить обновление.

Answer 3

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

Answer 4

Я не использовал его в БД, но при использовании в c языке для других целей, я следил за этим методом.

Рассмотрим Role1, роль2 ... Role5

Role => Bit-Pattern => Number 
------------------------------- 

Role1 => 00000001 => 2 
Role2 => 00000010 => 4 
Role3 => 00000100 => 8 
Role4 => 00001000 => 16 
Role5 => 00010000 => 32 

Поддерживайте один столбец называется roles в БД. И следить за этим,

Role1 + Role2 ==> 2 + 4 ==> 6 
Role1 + Role2 + Role5 ==> 2 + 4 + 32 ==> 38 
Role3 + Role4 ==> 8 + 16 ==> 24 

Таблица будет содержать только 38 для пользователя Role1 + Role2 + Role5.

Так, чтобы проверить, если пользователь имеет роль role3, сделать как Role3 ==>role_col ИЛИ Role3 т.е. (role_column || 8) будет возвращена истина.

Это экономит новый стол; может содержать разные числа до количества бит в поле (8 здесь 8 бит = 1 байт); Один простой запрос без соединения.

Answer 5

Есть 3 стратегии:

1. Только модели как обычный многие-ко-многим в базе данных, но следить за соблюдением лимита в триггерах или (менее в идеале) код клиента.

2. модель это как многие-ко-многим, но разместить дополнительные ограничения, чтобы ограничить количество строк:

   

   CHECK (ROLE_NO IN (1, 2, 3, 4, 5))

   Сочетание уникального ограничения U1 на {USER_ID, ROLE_NO} а выше CHECK гарантирует, что не может быть более пяти строк USER_ROLE, принадлежащих одному пользователю.

3. Просто пять NULL-состоянии 1-ко-многим:

   

---

Из всех этих стратегий, мой первый инстинкт должен был бы пойти (2) - это, пожалуй, «самый чистый» и легко поддается изменению, если ваши пределы когда-либо изменятся.

Может быть более опытным в некоторых сценариях (хотя в других случаях он может быть медленнее), но неудобно работать и, безусловно, менее гибко.

(1) Будет очень трудно реализовать правильное упражнение - вам нужно будет сделать свою блокировку очень осторожно, чтобы избежать проблем с параллелизмом и, вероятно, уничтожит масштабируемость в процессе.