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

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

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

你怎么看？

好吧,我会提出ORM框架(比如Hibernate)的要点是将数据库结构和对象模型分离,而不是为了促进它们的相同性.

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

另一方面,数据库开发人员经常认为数据库更为基础,并且没有充分的理由:通常很多应用程序需要针对单个数据库工作,数据库通常比应用程序更耐用,数据比应用程序更有价值,东西像那样.如果你的论点"好,Hibernate需要这样......",那么他们会打得很好.

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