面向对象的程序员如何掌握数据库驱动的编程方法？

人有伞我大头

我从事C＃和Java编程已经一年多了，对面向对象的编程有很好的了解，但我的新项目需要数据库驱动的模型。我正在使用它C＃和Linq，这似乎是一个非常强大的工具，但在设计数据库时遇到了麻烦。
我的两个主要问题是：
如何处理数据库中的继承？
假设我正在构建人员名册应用程序，并且有抽象类Event。我从事件中衍生出抽象类ShiftEvent和StaffEvent。然后，我有具体的类别Shift（从ShiftEvent派生）和StaffTimeOff（从StaffEvent派生）。还有其他派生类，但出于争论的目的，这些就足够了。
; }( e8 A0 i# q8 T我应该为ShiftEvents和StaffEvents提供单独的表格吗？也许我应该在每个特定的班级都有单独的表格？当与数据库交互时，这两种方法似乎都给我带来了问题。另一种方法可能是有一个事件表，它将为我的任何特定类别中的每个数据类型提供一个空列。所有这些方法都觉得它们可能会阻碍未来的可扩展性。我没有考虑过第三种方法。
我的第二个问题:
如何处理集合和一对多的关系？
假设我有一个Products类和一个Categories类别。每个类别的例子将包含一个或多个产品，但产品本身不应该有类别知识。如果要在数据库中实现此功能，则每个产品都需要一个类别ID，该ID映射到类别表。但这引入了比从OO我更喜欢的耦合。产品甚至不应该知道类别的存在，更不用说包含类别了ID数据字段！有没有更好的办法？
! R. T* {* B7 _. G. g                                                               
: ~- S2 N8 b9 o8 z. N    解决方案:                                                               
                                                                Linq to SQL使用各类表解决方案：
http://blogs.microsoft.co.il/blogs/bursteg/archive/2007/10/01/linq-to-sql-
2 ?5 p& a$ j8 P# {! \+ ninheritance.aspx
8 C7 C( J5 S/ _" j4 e其他解决方案(比如我最喜欢的)LLBLGen）允许使用其他模型。就个人而言，我喜欢带有区分符列的单表解决方案，但这可能是因为我们经常查询跨继承层次结构，所以我们将其视为常规查询，具体类型的查询只需要
; w2 @/ s/ u( c2 n) Vwhere”更改。
总之，我个人认为会OO映射到表中就是把购物车放在前面。一直有人声称，OO解决了与关系的阻抗不匹配…而且已经有很多了OO具体数据库。他们中没有一个人有这种关系的强大简单性。
相反，在设计数据库时，我倾向于考虑应用程序，将这些表示映射到实体并从那里构建。有些人认为这是在设计过程中OO但在我看来，数据层不应该在你的应用程序中说得足够高，这会影响高级系统的设计，仅仅因为你使用了关系模型
6 G1 n0 p) \: I) U" u/ H进行存储    。