ORM其实是在映射网络模型和关系模型,OO的关系模型无需映射,且更简单高效

O-R Mapping 从字面上理解是在 面向对象体系 与 关系数据库 之间进行映射.

不过最近为了写 TOB 的 ORK 模型资料, 更进一步研究了 Entity-Relationship 模型以及相关的 网络模型, 关系模型 和 Entity Set 模型. 然后有个惊人的发现:

  ORM 所支持的 POJO 模型本质上其实是网络模型, 而 O-R 的 Mapping 其实是在 网络模型 和 关系模型之间进行映射.

--有了这个发现, 总算对一直以来对 ORM 和 POJO 模型的一些感性的抵触有了一个理性的认识.

认定 ORM 所支持的 POJO 模型为 网络模型, 判断如下:

1. 对象之间的关联是通过 单边(Unidirectional)或者对等(Bidirectional)的引用(Reference)或者引用集合(Reference Set)建立起来的. 没有独立的 Relationship 载体.
2. 对等(Bidirectional)的引用或引用集合之间也存在不自然的单向性, 其中必有一方为 Owner, 而另一方为 Member. 这是网络模型的特有特征.

而关系模型下 实体 之间的关联是通过独立的 关系记录 代表的, 而 关系记录 上也可以有自己的属性, 很多情况下这些 关系属性 非常重要, 使关系模型能够比网络模型更接近现实世界的结构. 比如一辆汽车的组装模型, 用到某种型号的螺母, 而这种螺母的单车用量, 作为 车型 与 螺母型号 两个实体之间的 关系属性 才最为恰当.


人们一直认为 关系模型 与 面向对象体系 之间无法完美融合, 也遭遇了多方面的尝试失败, 但是以目前我的研究分析结果来看, 这其中的根本原因是大家还没有认识到这些失败的研究和尝试仅只是在用 面向对象的方法 去实现 网络模型 的持久数据管理系统.

目前成熟的面向对象数据库, 比如为 Java 和 .Net 设计的 db4o http://www.db4o.com 其实是网络数据库. 通用面向对象程序设计语言 (General Purpose Object Oriented Programming Language), 特别是广泛应用的一些, 像 C++, Java 方面, 始终没有本土的关系模型数据库出现. 而应用程序开发领域广泛采用了这些 通用面向对象程序设计语言, 并且难以割舍.

加上 Hibernate 所引领的层出不穷的 ORM 框架产品, 呈现给人一种感觉, 那就是, 面向对象 与 关系模型 水火不容, 只能 Mapping.

但是事实上, 众多传统关系数据库产品早已加入了面向对象的思想特性, 称为 Object Relational Database http://en.wikipedia.org/wiki/Object-relational_database, 像 Oracle 8 以后就是. 更有甚者比如 InterSystems 的 CACHÉ http://www.intersystems.com/cache/index.html, 自称为 Post-Relational Database, 而其实已经可以通过完全的面向对象的语言来进行数据库开发, 只不过用的是自家(Home Grown)的OO语言.

而通用OO语言一直没能融合关系模型的一个根本原因, 是大家总是拒绝向内存对象模型引入 "关系对象" 的概念, 而这是 关系模型 区别于 网络模型 的根本特征之一.

不过在传统的以磁盘为主体存储的数据库系统中, "关系对象" 所建立起来的 "关联" 自然而然的完全存在于逻辑上, 这同时也使得对 "关联" 的操作非常简单, 只有3件事:

1. 创建关系对象以建立关联
2. 删除关系对象以解除关联
3. 指定 JOIN 以引用关联

这里的 3, 限定了对关系数据的访问只能是通过 SQL, 一种不可能 OO 的语言.

目前的数据库市场仍然还是 以磁盘为主体(Disk Targeted) 的数据库产品的天下, 所以天经地义的, 关系模型与 SQL 之间, 在人们心里存在一个等号.

但是随着64位计算的日趋普及, 大内存也成为趋势, 于是现在已经出现了新的可能:
  在内存里建立关系模型的对象数据!
而基于日趋成熟的代码生成技术, 用注入的逻辑自动维护内存中关系模型下对象之间的引用关系也变为可能, 创建 和 删除 关系对象 时, 已经完全可以由数据库系统来自动修改它所连接起来的其他 持久对象 的 连接引用(Joint Reference), 从而维护整个内存中关系模型拓扑图的完整.

结论是: 对象技术其实不必借助 Mapping 就能实现和利用 关系模型, 现有的 ORM 其实只是在进行 OO语言编写的网络模型 到 关系模型 的映射.

面向对象的关系模型已经不是凭空的设想, 而是已经有可以实际应用的数据库产品, 就是我已经开发完成的 Ableverse The Object Base http://tob.ableverse.org, 它也不仅只是一个研究产品, 从开源的 WoW http://www.webofweb.net 产品表现, 可以看到它的商业质量.

不过 TOB 目前公开发行的还是版本 5, 开发时编译步骤还相对复杂.
计划元旦以后发布版本 6, 这个版本只需JDK6的javac, 没有任何多余步骤, 只需按平常开发Java程序的方法就可以编写基于TOB的持久应用, 通过Apache Ant, 也可以和流行Java IDE很好的集成.

基于TOB的持久应用, 全部源码只需Java类代码, 并且相对于 直接JDBC操作关系数据库, 或通过ORM方式, 数据库性能有几倍到几千倍的提升, 是关系数据库后台存储上的内存数据库性能.

有没有中文版的？俺国家四级也过了的，可看英文还是累的

只要还是“以磁盘为主体(Disk Targeted) 的数据库产品的天下”，ORM就有继续存在和发展的理由。

面向对象数据库，还处于摸索发展的阶段吧。我的感觉，面向对象本身就不容易与现实完全对应，所以还是关系型数据库来得简单实在。

啥时候有中文reference呀

主流数据库所应用的关系模型确实和面向对象理念存在不协调和不对称性，所以有了ORM这样的技术来辅助我们跨越这条“鸿沟”。

楼主的想法和实现个人觉得也是桥接这两者的一个优良的提案，可能也是楼主针对如今ORM存在的问题而给出的解决方案……
如今的计算机性能确实越来越多的依靠着内存来发挥，个人也比较认同“在内存里建立关系模型的对象数据!”这个手段。
只是不知道将来有没有好的机遇能够发展强大起来……

个人才疏学浅，没有和楼主具体探讨的实力，不过很期待你所展示的一些前景，同时也敬佩你的勇气和创造力。

还有一个继承的问题

postgresql是支持表的继承的。

当你数据库大于1G时，你的内存是不是至少也得512M？当然如果你能保证1G的数据内只有%10或者较少的活动数据那无话可说。当性能是个问题的时候你才想起要做些额外的工作让这些事情效率提高，比如增加缓存机制或写时拷贝等技术。

两点：
1、TOB给人以耳目一新的感觉，它抛弃掉了因为Java版本所带来的包袱，直接拥抱Mustang，新的技术平台给人新的自由；
2、让TOB平民化，可尝试从非技术角度，去推广。

TOB相关的中文内容我会首先发在 JavaEye, http://www.iteye.com/subject/TheObjectBase 专栏下, 如果感兴趣的话请继续关注.