数据库表设计;链接表或很少使用的外键？

Question

我的问题涉及针对特定场景的数据库中表的最佳实践设计。

假设我们有一家销售办公设备的公司，Say Printers。该公司还向购买了一台或多台打印机的客户提供服务合同。

鉴于上述信息，我们可以为我们的数据库推断出三个表：

• 客户
• 打印机
• 的ServiceContract

因此，对于给定的服务合同，我们指定为合同创建的客户，并指定一个或多个构成合同协议的打印机。

关于作为服务合同协议一部分的打印机，有两种方法可以实现数据库设计。

1. 第一个是在Printers表中创建一个ServiceContractID列，并在它与ServiceContracts表之间创建一个基本的主/外键关系。我用方法看到的唯一问题是打印机不必是服务合同的一部分，因此您可能在数据库中有数百甚至数千个打印机记录，其中许多不是合同的一部分，所以将此外键列用于许多记录。

2. 第二个选项是创建一个链接表，其中包含两个引用ServiceContracts表（它的主键）和Printers表（它的主键）的外键。组合此新表中的两列以生成唯一的复合主键。

好吧，这是我的窘境。我不认为这两种选择通常都是一个非常糟糕的想法，但我不知道这两个设计决策中哪一个是最佳实践。

欢迎所有评论。

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

希望有所帮助。我会有兴趣听听别人的想法。 。