sql - 面向对象的程序员如何了解数据库驱动的编程？

Question

我已经使用 C# 和 Java 进行编程一年多了，并且对面向对象编程有了很好的掌握，但是我的新副项目需要数据库驱动的模型。我正在使用 C# 和 Linq，这似乎是一个非常强大的工具，但我在围绕面向对象的方法设计数据库时遇到了麻烦。

我的两个主要问题是:

如何处理数据库中的继承？假设我正在构建一个员工排类应用程序，并且我有一个抽象类 Event。我从 Event 派生抽象类 ShiftEvent 和 StaffEvent。然后我有具体的类 Shift (派生自 ShiftEvent)和 StaffTimeOff (派生自 StaffEvent)。还有其他派生类，但为了论证这些已经足够了。

我应该为 ShiftEvents 和 StaffEvents 使用单独的表吗？也许我应该为每个具体类别设置单独的表？这两种方法似乎都会在与数据库交互时给我带来问题。另一种方法可能是拥有一个事件表，并且该表对于我的任何具体类中的每种数据类型都具有可为空的列。所有这些方法都感觉可能会阻碍 future 的可扩展性。很可能还有我没有考虑过的第三种方法。

我的第二个问题:

如何以面向对象的方式处理集合和一对多关系？

假设我有一个产品类和一个类别类。类别的每个实例将包含一个或多个产品，但产品本身不应该了解类别。如果我想在数据库中实现这一点，那么每个产品都需要一个映射到类别表的类别 ID。但这引入的耦合比我从面向对象的角度所希望的要多。产品甚至不应该知道类别的存在，更不用说有一个包含类别 ID 的数据字段了!有更好的办法吗？

Answer 1

Linq to SQL 使用每类一个表的解决方案:

http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/10/01/linq-to-sql-inheritance.aspx

其他解决方案(例如我最喜欢的 LLBLGen)允许其他模型。就我个人而言，我喜欢带有鉴别器列的单表解决方案，但这可能是因为我们经常跨继承层次结构进行查询，因此将其视为普通查询，而查询特定类型只需要更改“where”。

总而言之，我个人觉得将OO映射到表中是本末倒置。人们不断声称 OO 和关系之间的阻抗不匹配已经得到解决……并且已经有大量 OO 特定的数据库。他们都没有改变这种关系的强大简单性。

相反，我倾向于在设计数据库时考虑应用程序，将这些表映射到实体并从那里构建。有些人认为这是设计过程中面向对象的损失，但在我看来，数据层不应该在您的应用程序中进行足够高的讨论以影响高阶系统的设计，仅仅因为您使用了关系模型用于存储。