Проектирование базы данных - определение основных отношений «многие к одному»

Question

Это основной вопрос проектирования базы данных. Мне нужна таблица (или несколько таблиц), определяющая отношения между клиентами. Я хочу, чтобы PrimaryCustomer мог быть связан с несколькими SecondaryCustomers и иметь много SecondaryCustomers с одинаковыми отношениями.

PrimaryCustomerID  RelationshipID  SecondaryCustomerID

1) Если первичный ключ - {PrimaryCustomerID}, то у меня может быть только один связанный клиент любого типа.

2) Если первичный ключ - {PrimaryCustomerID, RelationshipID}, то у меня может быть только один связанный клиент для каждого типа отношений.

3) Если первичный ключ - {PrimaryCustomerID, RelationshipID, SecondaryCustomerID}, тогда я могу иметь все, что захочу, но все столбцы в качестве первичного ключа кажутся совершенно неправильными.

Как правильно все настроить?

Answer 1

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

Answer 2

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

• CustomerID как PK
• PrimaryCustomerID как FK дляCustomerID

Answer 3

Нет ничего плохого в № 3.

Если вам нужно предотвратить дублирование обратных связей, вы можете использовать

ALTER TABLE CustomerRelationship 
ADD CONSTRAINT chk_id CHECK (PrimaryCustomerId < SecondaryCustomerId);

Answer 4

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