我应该在应用中反映数据库结构吗？

Question

我正在设计一个允许在数据库中放入一些数据的应用程序。我想以某种方式反映应用程序中的数据库结构，例如，如果我有一个表，其中有部门和一个表与员工，并且有一个部门ID为3，两个员工与他有关的ID 44和123，在我的应用程序将有一个类别部门，其属性ID设置为3，它将引用两个Employee类，其Id设置为44和123.

我和我的同事谈过这件事，他说我不应该反映应用程序中的数据库结构 - 应用程序应该对数据源一无所知。这听起来很聪明但是如果我的类中没有Id属性（并且它们肯定反映了数据库结构），我就不可能知道哪个员工的属性被更改了，我将无法将数据放回数据库中。我很困惑 - 我听说过将数据库结构反映为对象的框架（例如hibernate），我不确定它是否如此糟糕。

你觉得怎么样？

Answer 1

好吧，我会提出ORM框架的点（比如Hibernate）是解耦数据库结构和对象模型，而不是为了促进它们的相同性。 / p>

关于如何设计对象模型和数据库模式，有不同的哲学，取决于你与谁交谈。许多应用程序开发人员认为数据库基本上是一个存储桶，让应用程序的需求驱动数据库架构的设计。因此，例如，应用程序开发人员可能会很好地允许给定ORM框架的特性强加于数据库架构设计，在数据库开发人员不想要的情况下，它们可能会很好地反规范化等等。

另一方面，数据库开发人员经常使数据库变得更加基础，并且没有充分的理由：通常很多应用程序需要针对单个数据库工作，数据库通常比应用程序更耐用，这些数据比应用程序更有价值。如果你的论点“好，Hibernate需要这样......”，那么他们会打得很好。

我认为两个阵营都会同意，但是没有必要 - 甚至没有 - 想要在课堂和桌子之间争取1-1关系。例如，在应用程序世界中正常运行的类之间的关系可以变成在数据库世界中表现不佳的联接。例如，有不同的方法将类继承映射到数据库模式，并且正确的选择取决于规范化和性能问题，而不是盲目授权将类/表映射设置为1-1。您可能拥有没有自己的独立生命周期的组件（例如，Address只与某些User存在关联，比如说），很多时候人们只会将其映射到用户表中的列列表，而不是使其成为第一类实体，从而节省了连接，从而强调了它的非独立性等。

Answer 2

理想情况下，您的应用程序无需了解对象的存储方式（如果存储对象）。但大多数情况下，您需要在会话之间持久保存对象，并且需要某种对象持久性，可以手动或通过OPF（Obj Persistence Framework）实现。 它通常是一个关系数据库，你描述的对象关系可以用一个简单的主细节实例来实现，其中DeptId是Employee表中的一个外键，用于将它连接到Department Table，或者它可以是一个关系表EmpDept持有所有相关的EmpId和DeptId 这个物理实现细节可以隐藏到业务逻辑中，但无论如何您仍然需要知道员工属于某个部门 所以你的同事不太对，因为你需要知道一个员工持有它所属的Dept_Id。

Answer 3

威利的答案非常好。就个人而言，我更喜欢使用数据库作为一个桶。我的提示是这样的：如果你真的希望你的数据模型和你的对象模型是相同的（并且它们完全没有问题！）使用对象数据库。因为，在这种情况下，关系层不会给你太多买。

如果您选择ActiveRecord风格的对象数据库（如SandstoneDB），您所做的就是：在不考虑数据存储的情况下创建域对象。当您的对象正常工作时，您将向其发送“保存”消息，并将其自身写入数据库。而已。没有配置！它会自动生成自己的id，这样你就可以从数据库中快速检索它。

如果您采用经典方式并使用RDBMS，您可以放弃数据库设计，但为什么要这样做？你没有设计你的桌子以获得乐趣。有些工具会自动生成表定义中的对象：没关系。他们通常提供一个良好的开端。如果出现问题，您只能更改对象，或仅更改数据定义，或同时更改两者。只需查看您的代码，看看哪些更方便。

尼科

Answer 4

您要找的是 Object Relational Mapper 。这是一个自动处理数据库和对象之间数据推送的框架。

Answer 5

应用程序应反映用户需求/用户故事。数据库应该是应用程序的逻辑数据存储。

Answer 6

我知道我不需要完全反映数据库结构（特别是如果它对应用程序没有帮助）但是在我提供的示例中我没有其他任何可以想到的方法可以让我识别员工记录在应用程序内部发生了变化，W需要在数据库中更改哪些数据 - 我是对的吗？ 我的意思是 - 我的Employee类将拥有它的ID属性并且该Id是数据库中记录的id是不是一个坏主意？