Дизайн базы данных — ассоциативные объекты

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

В приведенном ниже примере у меня есть две таблицы: «Люди» и «Роли». Теперь 1 человеку может быть назначено 0 или более ролей. Это довольно прямолинейно с отношениями «многие ко многим», но сложная часть возникает, когда вы хотите позволить пользователю выбирать, какую роль он в настоящее время «работает».

Скажем, у пользователя есть выбор из 5 ролей на выбор, и в зависимости от того, какую роль он выбрал в данный момент, приложение представит ему разные виды/меню/кнопки/и т. д.

Я вижу здесь два решения:

1: (см. верхнюю часть изображения по ссылке ниже)

В таблице лиц вы включаете FK, допускающий значение NULL, в отношение «многие ко многим» (объект ассоциации).

Из Википедии на ассоциативный объект

Кажется, что «другие объекты» могут ссылаться на эту связь. Я просто не совсем уверен, включает ли это сущности Roles и Persons.

Что мне нравится в этом дизайне, так это то, что довольно легко получить список всех разрешенных ролей для человека, а затем вы просто указываете на одну из этих разрешенных ролей, говоря: «Вы текущая/активная». Это также кажется хорошим способом убедиться, что пользователь может иметь роль только как текущую, если у него есть доступ к роли... Только я также вижу здесь потенциальную катастрофу: что, если FK в ссылках на таблицу лиц это отношение другого пользователя. Дизайн БД позволяет это. Это будет только код, который предотвращает это.

2: (см. нижнюю часть изображения по ссылке ниже)

Я придерживаюсь простой ассоциативной сущности, и вместо этого у меня есть таблица FK in person, которая указывает на определенную роль в таблице ролей.

Проблема здесь в том, что я получаю еще меньше помощи от дизайна БД, гарантируя, что «текущая роль» человека является ролью, которая на самом деле «разрешена».

Пример изображения

Буду признателен за любые мысли по этому поводу =)

ОБНОВЛЕНИЕ: я включу еще один вариант той же проблемы.

Две сущности: WorkOrders и Sites

  • 1 Сайт может иметь доступ ко многим заказам на работу
  • 1 WorkOrder может быть доступен многим сайтам

Таким образом, у нас есть отношение многие ко многим

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

Есть ли у нас «OwnerSiteId» в качестве столбца в таблице WorkOrder, или вместо этого можно было бы ссылаться на отношение «многие ко многим», говоря, что «тот один» является владельцем.


person Trond Blomholm Kvamme    schedule 16.10.2012    source источник
comment
аналогично: stackoverflow.com/ вопросы/12652152/   -  person Damir Sudarevic    schedule 17.10.2012


Ответы (2)


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

-Дизайн 1. Наличие ключа таблицы ROLE в таблице PERSON плюсы: это уменьшит присоединение, следовательно, затраты на работу с базой данных будут снижены. Минусы: Вы можете назначить пользователю роль, которой никогда не было в его списке разрешенных.

  • Дизайн 2. Наличие ключа таблицы Associate Entity в таблице PERSON плюсы: PERSON будут назначаться только те РОЛИ, которые ему разрешены. Минусы: одна дополнительная стоимость присоединения по сравнению с первым подходом.

Вывод: на вашем месте я выберу дизайн 1 и гарантирую назначение ролей из приложения.

person zaffargachal    schedule 16.10.2012

Сохраните текущую роль вместе с другими данными сеанса.

person Oswald    schedule 16.10.2012
comment
Да, для этой проблемы здесь я вижу, что это может быть решением. Только я вижу, что эта проблема возникает и в других вариантах. Пример: у нас есть две другие сущности, WorkOrders и Sites. WorkOrder принадлежит 1 сайту и может использоваться совместно с несколькими другими сайтами. Здесь вы снова получаете проблему. У вас есть несколько сайтов, которые должны иметь доступ к рабочему заданию, но только один из них является владельцем. - person Trond Blomholm Kvamme; 16.10.2012
comment
@TrondBlomholmKvamme Да, но все эти ссылки являются временными и не должны формально храниться в базе данных: это все сеансовые вещи. Если необходимо сохранить текущие данные, вы просто сохраните их как столбец объекта. В противном случае подумайте о том, чтобы последовать совету Освальда. - person Bohemian♦; 16.10.2012