我正在设计一个允许将一些数据放入数据库的应用程序。我想以某种方式反映应用程序中的数据库结构，例如，如果我有一个包含部门的表和一个包含员工的表，并且有一个 ID 为 3 的部门和两个与他相关的员工，ID 为 44 和 123，在我的应用程序将有一个属性 ID 设置为 3 的类 Department，它会引用两个 ID 设置为 44 和 123 的 Employee 类。
我和我的同事谈过这件事，他说我不应该在应用程序中反映数据库结构 - 应用程序应该对数据源一无所知。这听起来很聪明，但如果我的类中没有 Id 属性（它们肯定反映了数据库结构），我不可能知道哪个员工的属性已更改，我将无法将数据放回数据库中。我很困惑 - 我听说过将数据库结构反映为对象的框架（例如休眠），我不确定它是否如此糟糕。
你怎么看？
【问题讨论】：
标签： database-design
好吧，我会提出 ORM 框架（如 Hibernate）的目的是解耦数据库结构和对象模型，而不是促进它们的相同。
关于如何设计对象模型和数据库模式有不同的理念，这取决于您与谁交谈。许多应用程序开发人员将数据库基本上视为一个小桶，并让应用程序的需求驱动数据库架构的设计。因此，例如，应用程序开发人员可能会允许给定 ORM 框架的特性强加于 DB 架构设计，他们可能会在 DB 开发人员不希望的情况下对某些东西进行非规范化等等。
另一方面，DB 开发人员通常认为 DB 更基础，而且并非没有充分的理由：很多应用程序通常需要针对单个 DB 工作，而 DB 通常比应用程序更耐用，数据比应用程序更有价值，诸如此类。因此，如果您的论点是“好吧，Hibernate 需要这样那样......”，他们会打得很好。
我认为两个阵营都会同意，尽管没有必要——甚至不希望——争取类和表之间的 1-1 关系。例如，在应用程序世界中运行良好的类之间的关系可能会变成在数据库世界中表现不佳的连接。例如，将类继承映射到 DB 模式有不同的方法，并且正确的选择取决于规范化和性能问题，而不是盲目地要求类/表映射为 1-1。您可能拥有没有自己独立生命周期的组件（例如，Address 仅与某些 User 存在关系），并且很多时候人们只会将其映射到列列表在用户表中，而不是使其本身成为一等实体，从而节省连接，从而强调其非独立性质等。
【讨论】：
理想情况下，您的应用程序不需要了解对象的存储方式（如果它们完全存储的话）。但大多数时候，您需要在会话之间持久化对象，并且需要某种对象持久性，可以手动或通过 OPF（Obj 持久性框架）实现。
通常它将是一个关系数据库，您描述的对象关系可以通过一个简单的 Master Detail 案例来实现，其中 DeptId 是 Employee 表中的外键以将其连接到 Department 表，或者它可以是关系表 EmpDept持有所有相关的 EmpId 和 DeptId。
这个物理实现细节可以隐藏到业务逻辑中，但您仍然需要知道员工属于一个部门。
所以你的同事不太对，因为你需要知道员工持有它所属的 Dept_Id。
【讨论】：
威利的回答非常好。就个人而言，我更喜欢将数据库用作位桶。我的提示是这样的：如果你真的希望你的数据模型和你的对象模型是相同的（它们相同绝对没有错！）使用对象数据库。因为，在这种情况下，关系层不会给你买太多东西。
如果您选择 ActiveRecord 样式的对象数据库（如 SandstoneDB），您所做的是：您无需考虑数据存储即可创建域对象。当您的对象工作正常时，您向它发送“保存”消息，然后它将自己写入数据库。而已。没有配置！它会自动生成自己的 id，这样你就可以从数据库中快速检索到它。
如果您采用经典方式并使用 RDBMS，您可以摆脱数据库设计，但为什么要这样做呢？你设计你的桌子不是为了好玩。一些工具会从表定义中自动生成对象：这很好。它们通常提供一个良好的开端。如果出现问题，您可以仅更改对象，或仅更改数据定义，或两者兼而有之。看看你的代码，看看哪个更方便。
尼可
【讨论】：
您正在寻找的是 Object Relational Mapper。这是一个自动处理在数据库和对象之间推送数据的框架。
【讨论】：
应用程序应反映用户需求/用户故事。数据库应该是应用程序的逻辑数据存储。
【讨论】：
我知道我不需要准确反映数据库结构（尤其是如果它对应用程序没有帮助），但在我提供的示例中，我想不出其他方法可以让我确定哪个员工记录在应用程序内发生了更改，W 需要在数据库中更改哪些数据 - 我说的对吗？
我的意思是 - 我的 Employee 类将具有它的 ID 属性并且这个 Id 是数据库中记录的 ID，这是一个坏主意吗？
【讨论】：