请帮助我连接继承和关系概念

这被通俗地称为 Object-Relational Impedance Mismatch

模式继承 大多数关系数据库不支持模式继承。虽然理论上可以添加这样一个特性来减少与OOP的冲突,但关系支持者不太可能相信层次分类法和子类型的效用,因为他们倾向于认为基于集合的分类法或分类系统比树更强大、更灵活。OO倡导者指出,继承/子类型化模型不必局限于树(尽管这在许多流行的OO语言(如Java)中是一个限制),但非树OO解决方案被视为比关系数据库首选的基于集合的主题变化管理技术更难制定。至少,它们不同于关系代数中常用的技术。

另见: Agile Data C2 Wiki

Patterns of Enterprise Application Architecture . 它将向您展示如何用关系结构表达继承模式。

有一个 tutorial 在这类事情上。

关系范式和面向对象范式之间的鸿沟经常被讨论。

二者都 系统。你必须决定你的妥协更倾向于哪一方。

我认为这个问题中的继承模型是有缺陷的。它太字面化了,或者是基于现实世界。是的,可以说我是现实世界中的一名管理员,因此也是一名管理员 是一个 人。然而,对象设计和继承应该更多地基于代码空间中的表达和共享行为。我更倾向于用户扮演的角色。管理员是角色,或角色的实例,设置为特定状态。用户不是个人(例如,批处理作业可能需要用户帐户)。

在这种特殊情况下,您可以使用合成为管理员建模。Administrators表将提供任何附加的管理状态以及相应用户的密钥。用户FK也是您的管理员PK。

为什么继承如此重要 传统的关系结构?

OO之所以流行,是因为它比主流的过程模型有了显著的改进。通过使用继承,代码可以变得更可靠(通过类型检查)、更容易修改(通过方法专门化)和更容易测试(通过简单的行为重写)。与过程模型相比,OO是 易于使用开发高质量软件。

当然,OO和关系模型之间的映射存在困难。这被称为“对象-关系不匹配”,并被命名为 "the Vietnam of computer science" . 在关系数据库中存储OO数据有多种策略,但没有一种是完美的——现代使用中最流行的是基于 active record pattern .

在您的世界中,拥有“用户类型”的管理员意味着什么?

您可能暗示的语义是,某些代码在某处看到该用户类型,并授权具有该类型的用户的操作。那么,也许管理员可以创建其他用户?

class User() { viewData(){ ...} ; signReport() {...} }

还有一个具有额外功能的类管理员

class Administrator()  extends User {  createUser() {...}; approvePurchase() {...} }

Administrator类型的对象可以在用户可以使用的任何地方使用。这种多态行为在实现时可能会有所帮助。现在,您的数据库似乎支持这种情况。但是,当管理员执行特定任务只需要一点额外数据时,您会怎么做?例如,purchaseApproval()已达到某个限制,我们需要将该限制作为新字段,但它仅适用于管理员。

是的,当您映射到数据库或从数据库映射时,继承可能不是正确的工具。

例如,您可以在一台服务器和另一台服务器之间传递不同的“消息”。每个消息都有自己的逻辑,所以您需要不同的类(以避免出现巨大的switch()语句),但也有一些共同的部分,比如每个消息都需要知道如何将自身序列化/反序列化为流(这是消息的所有子类都必须覆盖的方法)。

规范化的关系数据库模式实际上不支持多态性,除非超出DBA界通常认为的“最佳实践”。这无论如何都不是一个新问题,这个问题本身已经用几种不同的方式解决了一千多次。

当您开始使用数据时,真正的问题就出现了——如果您使用的是数据集,那么在尝试实现任何类型的多态性时,您将继续面临挑战。但是,如果要将一组域实体映射到关系模型,您会发现有许多工具可以帮助您克服关系数据库模式的限制。

ADO.NET实体框架:

http://msdn.microsoft.com/en-us/library/bb386876.aspx

NHibernate:

http://nhforge.org/Default.aspx

管理员是用户类型为“Administrator”的用户的具体示例就是 "Single Table Inheritance" 图案这是在一些主要的orm中实现的。特别是“Rails ActiveRecord”和Hibernate。

Example