我有一些具有不同结构的表，但包含相同的数据（在示例中是名称和姓氏）。
编辑：演示结构小提琴 - http://sqlfiddle.com/#!2/cce568
但是现在我需要创建一些集合表来存储这些信息+一些更多细节（例如日期时间、公司名称、职位等）。根据剩余字段的上下文，该集合表可以多次包含某个实体。
请问有什么模式可以存储这个集体表吗？根据 Bill Carwin 的帖子 ( https://stackoverflow.com/a/562030/1092627 )，我可以将所有这些表合并为一个，但是如果我需要将一些信息直接添加到该表中该怎么办？
提前感谢您的意见。
Craig Larman 的书“Applying UML with Patterns”描述了这个问题的 3 个常见解决方案。
您的示例并不是特别有用-没有合乎逻辑的理由在您的数据库中使用 3 种不同的方式来管理一个人的姓名（尽管由于数据导入/导出的怪异而经常发生这种情况）。
但是，很常见的“人”实体可能是员工（带有employee_id）、联系人（带有指向潜在客户表的链接）或客户（带有customer_id 和指向订单表的链接） .
在拉曼的书中，他给出了 3 个解决方案。
一个表来统治所有这些 在这里，您创建一个包含所有已知列的表。这会创建一个混乱的表，并将了解持久化每个子类的规则的责任推到应用程序层——数据库不会强制要求客户拥有 customer_id。但是，它使连接更容易 - 任何需要链接到人员的表都可以链接到人员表。
超类表 这通过将公共属性提取到单个表中来清理事物——例如“person”——并将特定于子类的字段推送到子类表中。因此，您可能将“person”作为超类表，将“contact”、“employee”和“customer”表作为特定的子类数据。子类表有一个“person_id”列链接回超类表。这更复杂——在检索数据时它通常需要额外的连接——但也更不容易出错——你不会意外地破坏数据模型，因为错误会为“员工”写入无效属性。
每个子类的表- 这就是您所描述的。它在数据模型中引入了相当多的重复，并且您经常有条件连接 - “如果人员类型 = y，则在表 x 上连接”，这会使数据访问代码变得棘手。