在我们的数据库设计中，我们有几个表描述不同的对象，但它们具有相同的基本类型。由于描述实际表和每列的作用需要很长时间，我将尝试通过使用基于作业数据库的类似结构化示例来简化它。
假设我们有下表:
这些表彼此之间没有联系，但共享相同的列。所以第一步是统一相同的列并引入一个唯一的 personId:
现在我们有了 person 的“标题”列，然后使用 personId PK 作为 FK 使用 1 对 1 关系链接到更具体的工作表。在我们的用例中，一个人只能从事一份工作，因此 personId 在出租车司机、程序员和建筑 worker 表中也是唯一的。
虽然此结构有效，但我们现在有一个用例，在我们的应用程序中我们获取 personId 并希望获取相应工作表的数据。这给我们带来了一个问题，即我们无法立即知道拥有此 personId 的人正在从事何种工作。
我们提出了一些解决此问题的方案:
在后台处理
这意味着只保留架构原样并在后端代码中寻找正确的表。这可能意味着查看每个存在的表和/或构建一个半复杂的连接选择，我们必须在其中筛选所有列以找到已填充的列。
总而言之:可能但意味着很多不必要的选择。我们也希望在实际数据库中保留这种面向数据库的逻辑。
使用类型字段
这意味着在 Person 表中添加一个字段列，例如用数字填充以确定正确的子表，如:
因此，如果是出租车司机，您可以在类型中添加 0，如果是程序员，则可以添加 1，依此类推...
虽然这大大减少了后端逻辑的数量，但我们必须确保我们在 Type 字段中使用的数字在后端是已知的并且永远不会更改。
为每个表使用单独的 ID
这意味着每个作业在 Person 中都有自己的 ID(必须可以为空)，例如:
现在很容易找出每个人的工作，因为其他人的 ID 是空的。
所以我的问题是:这些设计中哪一个是最佳实践？我在这里错过了一个明显的解决方案吗？
最佳答案
Bill Karwin 对与此类似的问题做了很好的解释。 https://stackoverflow.com/a/695860/7451039
关于database - 亲子设计，轻松识别子类型，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/41941492/