Многие ко многим вопросам дизайна стола

Question

Изначально у меня в БД было две таблицы: [Свойство] и [Сотрудник].

Каждый сотрудник может иметь одно «Свойство дома», поэтому в таблице сотрудника есть поле HomePropertyID FK для свойства.

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

Итак, я создал таблицу [Employee2Property], в которой есть поля EmployeeID и PropertyID FK для моделирования этого отношения «многие ко многим».

Теперь я обнаружил, что мне нужно создать другие отношения «многие ко многим» между сотрудниками и имуществом. Например, если есть несколько сотрудников, которые являются управляющими для имущества, или несколько сотрудников, которые выполняют работы по обслуживанию объекта и т. Д.

Мои вопросы:

1. Должен ли я создавать отдельные таблицы «многие ко многим» для каждой из этих ситуаций или я должен просто создать еще одну таблицу, например [PropertyAssociatonType], в которой перечислены типы ассоциаций, которые сотрудник может иметь со свойством, и просто добавить поле FK в [Employee2Property], например PropertyAssociationTypeID, который объясняет, что такое связь? Мне любопытно о плюсах / минусах или есть другой лучший способ.
2. Неужели я идиот и так все делаю неправильно?

Спасибо за любые предложения:)

Answer 1

Это очень правильный вопрос. И ответ: это зависит

Следующие вещи предлагают использовать одно типизированное отношение M: N:

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

Если эти утверждения более неправильные, чем правильные, вам лучше использовать отдельные отношения.

Answer 2

Create Table Employee
(
    Id int not null Primary Key
    , ....
)
Create Table Property
(
    Id int not null Primary Key
    , ....
)
Create Table Role
(
    Name varchar(10) not null Primary Key
    , ....
)

В таблицу ролей вы помещаете такие вещи, как «Менеджер» и т. Д.

Create Table PropertyEmployeeRoles
(
    PropertyId int not null
    , EmployeeId int not null
    , RoleName varchar(10) not null
    , Constraint FK_PropertyEmployeeRoles_Properties
        Foreign Key( PropertyId )
        References dbo.Properties( Id )
    , Constraint FK_PropertyEmployeeRoles_Employees
        Foreign Key( EmployeeId )
        References dbo.Employees( Id )
    , Constraint FK_PropertyEmployeeRoles_Roles
        Foreign Key( RoleName )
        References dbo.Roles( Name )
    , Constraint UK_PropertyEmployeeRoles Unique ( PropertyId, EmployeeId, RoleName )
)

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

Answer 3

Ваш выбор должен руководствоваться двумя соображениями.

1. Насколько статичным будет список потенциальных типов ассоциаций? Вы уже должны добавлять новые, так что, похоже, ответ здесь - не очень. Если существует вероятность того, что этот список будет расти, придерживайтесь варианта B (одна таблица с дополнительным FK к таблице AssociationType)

2. Каковы вероятные схемы доступа к этим данным? Если будет необходимость доступа к отдельным типам ассоциаций, изолированным от всех других типов, тогда лучше использовать несколько таблиц. Но я бы только сделал это, список типов ассоциативных ссылок также был очень статичным