В настоящее время я разрабатываю модель базы данных, и я столкнулся с проблемой, в которой я хотел бы получить больше информации о том, что считается правильным способом ведения дел.
В приведенном ниже примере у меня есть две таблицы: «Люди» и «Роли». Теперь 1 человеку может быть назначено 0 или более ролей. Это довольно прямолинейно с отношениями «многие ко многим», но сложная часть возникает, когда вы хотите позволить пользователю выбирать, какую роль он в настоящее время «работает».
Скажем, у пользователя есть выбор из 5 ролей на выбор, и в зависимости от того, какую роль он выбрал в данный момент, приложение представит ему разные виды/меню/кнопки/и т. д.
Я вижу здесь два решения:
1: (см. верхнюю часть изображения по ссылке ниже)
В таблице лиц вы включаете FK, допускающий значение NULL, в отношение «многие ко многим» (объект ассоциации).
Из Википедии на ассоциативный объект
Кажется, что «другие объекты» могут ссылаться на эту связь. Я просто не совсем уверен, включает ли это сущности Roles и Persons.
Что мне нравится в этом дизайне, так это то, что довольно легко получить список всех разрешенных ролей для человека, а затем вы просто указываете на одну из этих разрешенных ролей, говоря: «Вы текущая/активная». Это также кажется хорошим способом убедиться, что пользователь может иметь роль только как текущую, если у него есть доступ к роли... Только я также вижу здесь потенциальную катастрофу: что, если FK в ссылках на таблицу лиц это отношение другого пользователя. Дизайн БД позволяет это. Это будет только код, который предотвращает это.
2: (см. нижнюю часть изображения по ссылке ниже)
Я придерживаюсь простой ассоциативной сущности, и вместо этого у меня есть таблица FK in person, которая указывает на определенную роль в таблице ролей.
Проблема здесь в том, что я получаю еще меньше помощи от дизайна БД, гарантируя, что «текущая роль» человека является ролью, которая на самом деле «разрешена».
Буду признателен за любые мысли по этому поводу =)
ОБНОВЛЕНИЕ: я включу еще один вариант той же проблемы.
Две сущности: WorkOrders и Sites
- 1 Сайт может иметь доступ ко многим заказам на работу
- 1 WorkOrder может быть доступен многим сайтам
Таким образом, у нас есть отношение многие ко многим
Проблема: как нам лучше всего сохранить в базе данных, какой сайт является владельцем заказа на работу, когда может быть только 1 сайт, которому принадлежит заказ на работу.
Есть ли у нас «OwnerSiteId» в качестве столбца в таблице WorkOrder, или вместо этого можно было бы ссылаться на отношение «многие ко многим», говоря, что «тот один» является владельцем.