数据库设计 - 一张表用于不同类型的事务

基本上有三个选项（通过三个选项的组合可能会变得复杂）：

1. 保持每张桌子分开
2. 将所有表格组合为一张主要表格
3. 使用关联关系：具有公共列的基表和非公共列的单个表

以下是一些需要考虑的因素：

• 这些真的代表同一个实体吗？如果是这样，那个实体是什么？根据您的示例（报价单、订单、发票和贷记凭证），这些对我来说是独立的实体。它们是“相关的”，但不是主实体的相同或子类型（例如具有 Employee 表以及具有根本不同属性的 ExemptEmployee 和 NonExemptEmployee 子表）。这倾向于保持表格分开。
• 是否需要查询 Quote UNION Order UNION Invoice？请注意，这不同于将 Quotes 加入 Orders（例如，获得成功销售的百分比）。如果您确实需要经常执行这些类型的查询，则支持使用单个表。如果您正在查看“订单的生命周期”，我可以看到这样做。另一方面，即使拆分为多个表，这仍然是一个简单的查询，所以这是一个次要的考虑因素。
• 是否存在并非所有类型都通用的列？您提到每种类型都有几个特殊字段。这意味着您可能在任何情况下都不想使用选项#2，因为选项#3 重新引入了相对简单的完整性约束。假设，在您的大表中，如果您正在执行订单，则需要三列，否则应该为 NULL。这样做对于关联表来说是微不足道的，但需要使用 One Big Table 方法检查约束。如果订单的 X 列需要是数字，而发票需要是文本，那只会让验证变得更加困难。
• 你改变过类型吗？不仅将报价数据复制到订单中，而且实际上将报价本身更改为订单。如果是这样，那就是支持一张大桌子的论据。但我不认为这是一个现实的业务流程。
• 您通常会收到多少订单？您获得的订单越多，您就越想拆分这些表格。对 X 页的扫描仍然比对 4X 页的扫描要好，并且由于对索引进行更细粒度的控制，单独的表增加了您能够进行查找而不是扫描的可能性。

基于这些考虑，我个人会将表格分开。尽管它们可能具有相似的属性，但它们是根本不同的实体。

然而，我会尝试做的是查看这些通用属性集，看看它们是否真的属于报价/订单/发票/信用备忘录，或者将它们规范化到他们自己的表格中是否会是一个更好的主意。例如，如果您有客户名字、客户姓氏、客户街道 1 等，将其拆分为客户键（或客户和地址键，取决于具体情况）可以减少每个中的列总数四个主要实体中，减少重复并获得正常化的其他好处。

有可能您已经将所有内容进行了最大程度的规范化，并且实际上每个实体确实合法地具有 50 个共同的属性。在这种情况下，我仍然会保留单独的表格，因为您谈论的是根本不同的事情，而这些事情恰好相互关联。

凯文做出了出色的回应。我也会选择 nr。3.

但最终归结为两件事：

• 桌子的大小

• 查询的复杂性。

表的大小增加了规范化的需要，反之亦然查询的复杂性。

或者说简单点：如果您经常需要合并这些表，请考虑一张大表。如果行数很大，请规范化。或者，如果您的情况介于两者之间，请使用正确的（从数据库完整性的角度来看）解决方案 - 分开。