sql - 这些子类化方法中的任何一种都有潜在的缺点吗？

Question

想象一下，您有几个代表活动的表格：

• 过程活动
• 医疗活动
• 维护活动
• 物流活动

你现在意识到一切都是活动，那么，你会怎么做？

1. 您创建一个名为“活动”的主表，并为这些值添加一个类型字段：流程、医疗、维护、后勤或
2. 您创建一个超级活动表，并为每个子类创建一个只有主键的表，因为知道两个子类都没有唯一字段

我可以想到一些参与决策的利弊：

第一种方法：

1. 活动中的 CRUD 操作将意味着在两个不同的表中工作
2. 简化 ER 图
3. 失去完整性约束

第二种方法：

1. 维持这种关系的两个索引将保存在两个不同的地方
2. 语义

在这两种方法中是否有任何潜在的性能或其他后果？

Answer 1

我只会使用一个主 Activity 表，其中包含所有四种活动类型共有的数据，可以拆分成它。这还需要一个 ActivityTypeId 来指示它是哪种类型的 Activity 以及要在哪个表中查找详细信息。

假设有共同的数据：

• 优点：将数据从更详细的类型中适当地抽象为常见类型。
• 缺点：编码稍微复杂但不会太多

假设有最少的公共数据：

• 优点：真的没有
• 缺点：对具有统一整体（一个 xActivity）的数据进行不恰当的抽象，分散在 2 个地方而不是一个地方。

需要多少通用数据？这就是您的经验和判断的来源。您还需要考虑以下因素：是否会有一个查询屏幕列出所有类型的活动？如果是这样，是否可以将此查询中的列放在一个表中而不破坏数据（例如，对于一个列活动类型 1 有一个字符串，类型 2 有一个日期等）？

恐怕没有简单的答案。