«один-ко-многим» моделирования вопрос

Question

Что такое лучший способ моделирования следующие ...

Предположим у меня есть два объекта: Agency и Publisher, и оба имеют отношение 1-к-п к Employee , Это истинное отношение 1 к n, так как каждый Employee может работать только для одного Agency или одного Publisher. Предположим далее, что я не могу ввести супертип (например, Employer), который содержит отношения 1-к-n.

Моего предпочтительное решения является внешним ключом в Employee, который могут либо ссылка на первичный ключ Agency или Publisher (все мои первичные ключи 64-разрядные идентификаторы, которые являются уникальными для всей базы данных). Однако теперь я не смогу сопоставить двунаправленную связь, не указывая в Employee, является ли это отношением Agency или Publisher.

Моим другим вариантом является использование двух таблиц, AgencyEmployee и PublisherEmployee, которые затем могут быть связаны как традиционные двунаправленные ассоциации 1-на-n.

Что вы считаете лучшей практикой в ​​этой ситуации?

ОБНОВЛЕНИЕ: Спасибо за отличные ответы за такое короткое время! Что вы думаете о следующем решении: внешние ключи в Employee для обоих Agency и Publisher, такие как agency_id и publisher_id?

Answer 1

Лучшей практикой, вероятно, будет введение класса Employer.

Разделение сотрудника на агентствоEmployee и PublisherEmployee, с другой стороны, было бы Bad Thing ™.

Если вы не указали работодателю, я бы указал на тип работодателя (агентство или издателя) в Employee.

Ответ на обновленный вопрос:

Это вариант, но employer_type лучше, потому что:

1. Вы можете добавить другие типы работодателя в будущем
2. Там будет пустое поле в каждой строке таблицы Employees.

Answer 2

Похоже, что это может быть смоделировано как ternary relationship. Посмотрите, нравится ли вам подход, принятый в этой статье MSDN.

Answer 3

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

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

Мое последнее предпочтение было бы аналогично вашему предложению, имеющему одну таблицу для AgencyEmployees и одну для PublisherEmployees. Но я разделил бы это на один шаг дальше ...

Table1: Agency    (id, name, etc) 
Table2: Publisher   (id, name, etc) 
Table3: Employee   (id, name, etc) 
Table4: AgencyEmployees  (agency_id, employee_id) 
Table5: PublisherEmployees (publisher_id, employee_id) 

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

Table1: Agency    (id, name, etc) 
Table2: Publisher   (id, name, etc) 
Table3: Employee   (id, name, etc) 
Table4: AgencyEmployees  (agency_id, employee_id, start_date, leave_date) 
Table5: PublisherEmployees (publisher_id, employee_id, start_date, leave_date) 

Это не обеспечивает 1 работодателя на одного работника в любое время, но это может быть обеспечено с помощью хранимых процедур, GUI и т.д. ..

Answer 4

Я использовал этот подход:

Employee.EmployerType ('АГЕНТСТВО' или 'ИЗДАТЕЛЬ')

Employee.EmployerID (AgencyID или PublisherID)

Он работает нормально, но вам нужен оператор case во многих ваших SQL. Также, если вы используете ORM, вы теряете отношения FK.

Я перемещаю большую часть своего кода в отношения n: m, чтобы воспользоваться нашей поддержкой ORMs FK.

Answer 5

Очевидно предприятие работодателя было бы предпочтительнее, но в остальном ...

Имея AgencyEmployee & таблицы PublisherEmployee означает, что будет трудно определить, если работник принадлежит к той или иной категории.

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

Из интереса, почему бы вам не добавить AgencyEmployee & PublisherEmployee таблицы, но не добавить таблицу Employer? Просто любопытно ...

Answer 6

A +1 для Can Berk Güder.

Технически, введение супертипа работодателя означает, что вы вводите отношение Работодателя со всеми атрибутами, присущими Агентству и Издателю, агентской спецификой (не уверен, как называть это) отношение с ключом Работодателя и всеми атрибутами Агентства и Работодателем ключ как внешний ключ, затем агентство как запрос или представление, которое просто присоединяется к агентству с работодателем, а также для издателя.

Может быть немного громоздким, чтобы данные агентства и издателя распространялись по двум таблицам, к которым вы должны присоединиться каждый раз, но альтернативой является запись большинства ваших запросов, связанных с сотрудниками, дважды, после использования Агентства и после использования Publisher , а затем использовать свои союзы для объединения результатов. (Я не видел конструктора запросов, который помогает с такими базовыми вещами, как это.) Я должен был сделать это для проекта, который использовал подход «без супертипов», и я не хочу повторять это снова.

BTW тернарные отношения и даже отношения n-to-n не являются хорошей практикой дизайна, если вы спросите меня. Использование только функций (например, 1-к-n и 1-к-1), например. ограничения становятся намного легче сформулировать.