Дизайн таблицы базы данных;таблицы ссылок или редко используемый внешний ключ?

Question

Мой вопрос касается наилучшей практики проектирования таблиц в базе данных для конкретного сценария.

Скажем, у нас есть компания, которая продает оргтехнику, скажем, Принтеры.Эта компания также предлагает договоры на обслуживание клиентам, которые приобрели 1 или более своих принтеров.

С учетом приведенной выше информации мы можем вывести три таблицы для нашей базы данных:

• Клиент
• Принтер
• ServiceContract

Таким образом, для данного контракта на обслуживание мы указываем, для какого Клиента создан контракт, и назначаем 1 или более принтеров, которые составляют контрактное соглашение.

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

1. Первый - создать ServiceContractIDстолбца в таблице «Принтеры» и создайте базовое отношение первичного / внешнего ключа между ним и таблицей ServiceContracts.Единственная проблема, с которой я сталкиваюсь при подходе, заключается в том, что принтеры не обязательно должны быть частью контракта на обслуживание, и поэтому в базе данных могут быть сотни или даже тысячи записей о принтерах, многие из которых не являются частью контракта, поэтомупри этом этот столбец внешнего ключа не используется для многих записей.

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

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

Все комментарии приветствуются.

Answer 1

Я думаю, не зная всей вашей проблемы, что второй вариант предпочтительнее.(т. е. более правильно нормализовано - в общем)

Второй вариант позволил бы обеспечить некоторую гибкость бизнес-правил, которую вы, возможно, еще не разработали (или ваша бизнес-модель может измениться).: даты могут стать важными.Например, можно использовать один и тот же ServiceContract, даже если бизнес принимает решение по какому-либо правилу, так как все принтеры покрываются в течение одного года после покупки этим клиентом.где одно и то же соглашение распространяется только на многие покупки.

, поэтому вариант 2 дает вам гибкость для добавления других атрибутов в отношения ...

Answer 2

Если я правильно понимаю ваш проблемный домен, правильным способом для этого будет вариант 2. Похоже, что у клиента может быть 0-много контрактов на обслуживание, у контракта на обслуживание может быть 0-много принтеров, связанных с ним принтер может быть связан с 0-1 контрактами на обслуживание (если срок действия контракта не истекает и не возобновляется с новым контрактом, в этом случае принтер может иметь много-много.

Customers:
    PK
    CustomerInfo

Printers:
    PK
    PrinterInfo
    FK on Customer PK

ServiceContracts:
    PK
    FK on Customer

// This creates a composite PK for the Contract_Printers Table:
Contract_Printers:
    FK on Contract PK
    FK on Printer PK

Надеюсь, это поможет. Мне будет интересно услышать, что думают другие. , .