当您需要将继承类继承到不支持继承的关系数据库时，有什么技巧/技巧？数据库继承技术？
说我有这个经典的例子：
Person -> Employee -> Manager
-> Team lead
-> Developer
-> Customer -> PrivilegedCustomer
-> EnterpriseCustomer
什么是设计数据库的可用技术？每个的优缺点？
p.s.我已经搜索并发现了关于数据库继承的几个问题，但大部分都是关于更改为原生支持它的数据库引擎。但是，让我们说，我坚持SQL Server 2005 ...我的选择是什么？
常见的三种策略：
中包含每个类和外键回到顶级超类表中定义的属性层次结构中每类创建一个表。所以你可能有一个vehicle表和其他表，如car和airplane有vehicle_id列。这里的缺点是你可能需要执行很多连接才能获得一个类的类型。
中包含的所有属性的层次中的每个类创建一个表。这一点可能会变得棘手，因为除非您使用类似于序列的东西，否则在所有表格中维护公共ID并不容易。对超类型的查询需要针对所有有问题的表进行联合。
为整个类层次结构创建一个表。这消除了连接和联合，但要求所有类属性的所有列都放在一个表中。您可能需要将大多数列保留为空，因为某些列不适用于其他类型的记录。例如，vehicle表可能包含一个名为wingspan的列，该列对应于Airplane类型。如果将此列设置为NOT NULL，则表中插入Car的任何实例都将需要wingspan的值，即使值NULL可能更有意义。如果您将列置空，您可能可以通过检查约束来解决这个问题，但它可能会变得很难看。 （Single Table Inheritance）
查询的复杂性是我关心的地方。它可能需要一些DAL部分的技巧才能正确使用。 – chakrit 2008-12-22 16:35:35
对于查询复杂性＃3听起来最好。此外，在某些DBMS（如Postgres）中，您可以通过检查约束为每个特定的子类型强制实现非空，即使这些列都是可以为空的。 – 2011-06-15 13:45:09
第8章继承在下面的链接中的映射也讨论了这一点。 http://nhibernate.info/doc/nh/en/index.html#inheritance
这是NHibernate的文件。
在某些情况下要小心数据库的继承 - 我们在我们的审计策略应用程序中实现了它，最终导致了性能瓶颈/噩梦。
问题是我们使用的基表只是插入并且快速变化，所以我们最终以死锁全部为。我们目前正在计划将这些分解成自己的表格，因为在15个不同的表格中使用相同的列与表演噩梦相比，令人头疼的事情非常值得。实体框架不一定能够有效地处理继承（这是微软公司已知的一个问题），这一事实也加剧了这一点。
反正只是想我会分享一些知识，因为我们已经通过在这个问题上拧干。
相关问题：http://stackoverflow.com/questions/190296/how-do-you-effectively-model-inheritance-in-a-database – 2009-04-24 17:33:57