Несколько внешних ключей между двумя таблицами

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

Tbl_Event 

EventID Description Location

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

Tbl_Staff 

StaffID Name

персонала Теперь каждое событие может иметь несколько сотрудников, для достижения этой цели я создал новую таблицу

tbl_Event_Staff 

    RecordID StaffID EventID

StaffID и EventID имеют уникальное ограничение COMBINED. Существует дополнительное условие, когда одним из сотрудников должен быть руководитель мероприятия. Что является наилучшим решением для достижения этой цели, я должен добавить дополнительную колонку в tbl_event - SupervisorID

Tbl_Event 

EventID Description Location SupervisorID

и связать его с tbl_Event_Staff на StaffID (в данном случае будет внешние ключи между этими двумя таблицами - EventID и StaffID)

или * Я не думаю, что это лучшее решение для избыточных данных.

Должен ли я добавить дополнительный столбец для tbl_Event_Staff - isSupervisor (bool), и для каждой строки есть логическая переменная, которая означает, что персонал для этого события является супервизором или нет.

tbl_Event_Staff 

    RecordID StaffID EventID IsSupervisor 
     1  10  3   true 
     2  20  3   false 
     3  30  3   false

или

Есть ли альтернативное решение?

источник

2013-04-26 Abhi.Net

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

Сведения о том, как это сделать, могут различаться между базами данных - в некоторых системах это может потребоваться с помощью триггера. В SQL Server, это может быть сделано с помощью отфильтрованного индекса:

CREATE UNIQUE INDEX ON EventStaff (EventID) WHERE IsSupervisor = 1

Я также рекомендую покончив с tbl_ префиксов - нет здравомыслящих причин использовать префиксы для различения типов объектов в SQL - синтаксис языка означает, что вы можете указать тип объекта исключительно по его позиции в запросе - за исключением одной ситуации.

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

источник

2013-04-26 06:34:22

Спасибо за ваш вклад. Это лучший подход для решения этой проблемы? У меня будет много избыточных данных, и будет намного сложнее обновить базу данных. Хотя, подумайте об этом каждый раз, когда пользователь устанавливает штат в качестве супервизора, я могу пропустить все идентификаторы персонала для этого события и установить флаг IsSupervisor в false, но тогда эта таблица не будет нормализована должным образом. думаю, это цена, которую мне придется заплатить. –

@ Abhi.Net. На данный момент у вас есть два ответа, и мы не согласны. Возьмите это как знак того, что нет «лучшего подхода». Только вы знаете, какие запросы и операции вам понадобятся для поддержки этих структур данных. И, как я указываю в своей стороне, вы можете (из любого дизайна) создавать представления, имитирующие другой дизайн, поэтому, если позже вы решите, что другая структура более уместна, вы можете ее перестроить, а затем только перезаписать их запросов, которые извлекают выгоду из перепроектирования. –

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

Первое решение лучше, потому что оно автоматически защищает вас от создания событий с нулевыми супервизорами и/или событиями с несколькими супервизорами: когда столбец supervisor_id события не имеет значения NULL, ваша РСУБД гарантирует, что для каждого мероприятие.

Если вам нужно получить результаты в виде таблицы с true/false индикатором маркировки супервизора, вы всегда можете получить этот результат путем присоединения к Tbl_Event и сравнивая Tbl_Event.supervisor с tbl_Event_Staff.StaffID.

источник

2013-04-26 03:17:06 dasblinkenlight

Но стоит ли иметь отношение внешних ключей между столбцами, и ни один из них не является первичными ключами? В tbl_event и tbl_event_staff и staffid, и supervisorID являются не ключевыми атрибутами. –

@ Abhi.Net Я бы не связывал его с 'tbl_Event_Staff', я бы связал его напрямую с' Tbl_Staff', где «StaffID» является первичным ключом. – dasblinkenlight

Я действительно думал об этом, но в этом случае у меня может быть staffId в моем tbl_event, пока нет записи в tbl_staff_event. Это означает, что персонал работает в качестве наблюдателя в случае, если у него нет записи в tbl_staff_event. –

Несколько внешних ключей между двумя таблицами

ответ

Смежные вопросы