Database 数据库继承技术？

当您需要将继承类持久化到不支持继承的关系数据库时，有哪些技巧/技巧

假设我有一个经典的例子：

Person -> Employee -> Manager
                   -> Team lead
                   -> Developer
       -> Customer -> PrivilegedCustomer
                   -> EnterpriseCustomer

设计数据库的可用技术有哪些？各有利弊

---

p、 我已经搜索并发现了几个关于数据库继承的问题，但大多数问题都是关于转换为本地支持它的数据库引擎。但假设我一直使用SQL Server 2005。。。我的选择是什么？

三种常见策略：

为层次结构中的每个类创建一个表，其中包含为每个类定义的属性和返回顶级超类表的外键。因此，您可能有一个

vehicle

表，其中包含

car

和

frame

等具有

vehicle\u id

列的其他表。这里的缺点是，您可能需要执行大量的联接才能得到一个类类型

为层次结构中包含所有属性的每个类创建一个表。这可能会变得很棘手，因为除非您使用类似于序列的东西，否则在所有表中维护一个公共ID并不容易。对超类类型的查询需要对所有相关表进行联合

为整个类层次结构创建一个表。这消除了联接和联合，但要求所有类属性的所有列都位于一个表中。您可能需要将大多数列保留为空，因为某些列不会应用于其他类型的记录。例如，

vehicle

表可能包含一个名为

wingspan

的列，该列对应于

飞机

类型。如果将此列设置为非空，则插入表中的

Car

的任何实例都需要

wingspan

的值，即使

NULL

的值可能更有意义。如果将列保留为空，则可以使用检查约束解决此问题，但它可能会变得很糟糕。（）

---

第八章。下面链接中的继承映射也讨论了这一点

---

这是NHibernate文档。

在某些情况下要小心数据库继承-我们在应用程序中实现了它以实现审计策略，最终导致性能瓶颈/噩梦

问题是，我们使用的基表是insert-only，并且变化很快，所以我们最终遇到的是到处都是死锁。我们目前正计划将这些列拆分为各自的表，因为在15个不同的表中有相同的列而不是性能噩梦，这是非常值得的。实体框架不一定能有效地处理继承（这是Microsoft已知的一个问题），这一事实也加剧了这种情况

---

无论如何，我想我应该分享一些知识，因为我们已经讨论了这个问题。

我关心的是查询的复杂性。可能需要在DAL部分使用一些技巧才能使其正确。对于查询复杂性，3听起来最好。此外，在某些DBMS（如Postgres）中，您可以通过检查约束为每个特定子类型强制非空，即使列都可以为空。我不知道这是否是一个选项，但您不使用1。并使用视图访问数据，这样您只能在一个点中获得连接？相关问题：那么您正在执行#1，并且正在（已经）移动到#2？（关于cliff.meyers解决方案）