对于应用系统。
长久以来存在着两个建模。
一个是在数据库层的ER关系模型，
另一个是在应用系统里的OO模型。
应用系统为什么开发麻烦，很大一个原因是因为要在一套系统里同时维护两个模型，动了ER模型，必然会影响到OO模型，动了OO模型必然会影响到ER模型。我们很大一部分精力是在维护这两个模型的统一。这完全是做无用功。
一个有效率的系统只应该存在一个现实模型。这样就不必为了维护与另一个模型的对应而绞尽脑汁。
在OO思想还未出现的时候，是没有这种烦恼的。那时的应用系统是数据库驱动型，只需要在数据库里建立一个ER模型，则整个现实的模型就已经建立，剩下的只是操作和显示。
OO的引入是对应用系统开发的一次变革，但遗憾的是数据库方面并没有同时跟进。面向对象的开发其中心思想是在应用系统里用对象来建立一个现实系统的模型。要遵循面向对象的开发方式则必然会在OO层面建立一个模型，但传统的数据库模型并没有抛弃，同样存在在系统里。这样我们需要建两次模，同时需要维护两个模型，而且还需要维护这两个模型之间的统一。这无疑是一个愚蠢的做法。
有两条出路来解决这个问题。
第一，以数据库模型为标准，放弃系统的OO模型，这就是数据库驱动的开发方式。不需要对象。这种开发方式很高效，但麻烦也是显而易见的，不够灵活。当需求发生变动的时候，改动ER模型会带来巨大的影响。当初抛弃这种方式也应该是为了解决这个问题吧。
第二：抛弃ER模型，只专注于OO模型。这样系统比较直观，对于系统的扩展和维护人员的接手都是比较容易的。但麻烦是对象需要存储。这就需要以一种结构存储在数据库中。这种结构绝对不能是ER关系。这就需要创造出另一种关系模型。然后在对象与数据库之间做好转换。数据库层对对象来说是不可见的，开发人员只需关心对象的模型就OK。在对象与数据存储上需要提供一种转换，比如随着业务的变更，对象需要新增一个属性，那么必须要提供一个后台的转换机制，把这个新增的属性自动添加到数据库中。还需要提供一个对象的查询机制。