database-design - 我应该在应用程序中反射(reflect)数据库结构吗？

Question

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

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

你怎么看？

Answer 1

好吧，我愿意提供 ORM 框架之点 (如Hibernate)是将数据库结构和对象模型解耦，而不是促进它们的相同。

关于如何设计对象模型和数据库模式有不同的哲学，这取决于您与谁交谈。许多 应用程序开发人员 将 DB 视为一个基本的桶，让应用程序的需求驱动 DB 架构的设计。因此，例如应用程序开发人员可能会允许给定 ORM 框架的特性强加给 DB 模式设计，他们可能会在 DB 开发人员不想的情况下对某些东西进行非规范化，等等。

另一边，数据库开发人员 通常将数据库视为更基础，并非没有充分理由:通常许多应用程序需要针对单个数据库工作，数据库通常比应用程序更耐用，数据比应用程序更有值(value)，诸如此类。因此，如果您的论点是“好吧，Hibernate 需要某某......”

我认为两个阵营都会同意，尽管有 不需要——甚至不想——争取类和表之间的 1-1 关系 .例如，在应用程序世界中运行良好的类之间的关系可能会变成在数据库世界中表现不佳的联接。例如，有不同的方法可以将类继承映射到 DB 模式，正确的选择取决于规范化和性能问题，而不是盲目要求使类/表映射为 1-1。您可能有没有自己独立生命周期的组件(例如，一个 Address 仅与某些 User 相关，例如)，并且很多时候人们只会将其映射到列列表在用户表中，而不是使其本身成为一流的实体，从而节省了连接，从而强调了其非独立性等。