O/R Mapping技术的出发点是对象的持久化，其最初的目标是“研究如何把内存中的对象状态在程序结束之后仍然能够保存起来”。由于数据库是保存结构化信息的最好选择，而市面上绝大多数数据库是关系型数据库。对象模型与关系模型看问题的出发点不同，他们之间存在着许多不匹配的地方，但基于某些原则又可以互相转换。于是，为了把对象模型的数据保存在关系模型之中，就诞生了O/R Mapping概念。

　　随着O/R Mapping技术的继续发展，人们开始希望用O/R Mapping技术来隔离应用程序与数据库，人们希望只要设计对象类来描述现实的业务对象即可，不用考虑数据库的存储问题。这种思想本身很好，但其只看到了开发的方便性的一面。

　　其实，O/R Mapping只解决了数据存储问题。但令人遗憾的是，数据存储并只是信息系统的基本功能，而信息的管理、索引、检索、统计、分析和数据挖掘等等才是信息系统最重要的功能！

　　对象模型中的对象个体是离散的，而关系模型中的元组是集合概念。集合概念天生就用来操纵大量元素的，再配有严谨的关系理论支持，与实践检验过的关系数据库技术，其数据库性能是有充分保证的。

　　而O/R Mapping是从单个的对象上去思考问题的，其只关注程序对象与关系表的映射关系，没有充分考虑对象的索引、检索和聚集性操作要求，必然导致程序运行的低效率。这是由O/R Mapping本身概念引起的，没有其他办法解决，除非重新定义O/R Mapping概念，从对象集合的新出发点去设计O/R Mapping。

　　“不玩对象，玩对象集合”就是这种思想的改进，但这已经不叫O/R Mapping，而叫做“对象关系数据库”，或者“关系型对象数据库”，最终会叫作“对象数据库”。

　　对象数据库依然向程序语言提供类似“记录集”的概念，不过应该称为“对象集”。其访问数据库的方式与传统的关系数据库访问方式没什么不同，依然可以使用ODBC、ADO、JDBC、ADO.NET等方式来访问，依然提供类似SQL的强大查询语言，不过将被称为OOSQL或OQL。

　　对象数据库的外表与关系数据似乎没有两样，区别就在于数据库的内涵。元组将会被对象集替代，表的概念将会被类的概念替代，记录或者行的概念将会被对象的概念替代，字段或者列的概念将会被属性的概念替代。通过这样的替代，数据库内部就是对象模型，原来的关系依然存在并适用，因为对象模型与关系模型并不矛盾。

　　用对象模型能更好地描述业务模型，对象模型可以让我们将思考的问题分层次解决。例如，所以与你做生意的都可以抽象为客商，而供应商是客商的子类，客户也是客商的子类。采购模块需要关联供应商类，销售模块需要关联客户类。但财务模块嘛，只需要关联上层的客商类，供应商与客户的财务问题自然解决。如果用原来的关系模型设计，恐怕就会为供应商和客户单独做财务模块。这就是数据库内涵的不同。

　　最重要的是，这样的对象模型依然继承了着关系数据强大的查询与检索数据的能力，OOSQL或OQL语言除了保留原来SQL强大的查询功能之外，还将可能提供新的对象化的查询功能。这是O/R Mapping技术所无法完成的。


李战.深圳　3005-8-4