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

Question

我的问题与特定场景下数据库表的最佳实践设计有关。

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

根据以上信息，我们可以为我们的数据库推导出三个表:

• 客户
• 打印机
• 服务契约(Contract)

因此，对于给定的服务契约(Contract)，我们指定为哪个客户创建契约(Contract)，并分配 1 台或多台构成契约(Contract)协议(protocol)的打印机。

关于作为服务契约(Contract)协议(protocol)一部分的打印机，我们可以通过两种方式进行数据库设计。

1. 首先是在 Printers 表中创建一个 ServiceContractID 列，并在它与 ServiceContracts 表之间创建一个基本的主键/外键关系。我看到的唯一问题是打印机不必成为服务契约(Contract)的一部分，因此数据库中可能有数百甚至数千条打印机记录，其中许多不是契约(Contract)的一部分，所以许多记录未使用此外键列。

2. 第二个选项是创建一个链接表，该表将包含 2 个外键，同时引用 ServiceContracts 表(它是主键)和 Printers 表(它是主键)。合并此新表中的两列以生成唯一的复合主键。

好吧，这是我的困惑。我不认为这两个选项通常是一个非常糟糕的主意，但我坚持要知道这两个设计决策中的哪一个是最佳实践。

欢迎所有评论。

Answer 1

我认为，在不了解您的整个问题的情况下，第二种选择更可取。 (即更恰本地归一化——一般来说)

第二个选项允许一些您可能还没有想到的业务规则灵 active (或者您的业务模型可能会改变)。

例如:日期可能变得很重要。例如，即使业务决定了某些规则，也可以使用相同的服务契约(Contract)，例如所有打印机在该客户购买后保修一年。同一协议(protocol)仅涵盖许多购买。

因此选项 2 使您可以灵活地在关系中添加其他属性...