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

TOB开辟的是一条 面向对象的内存关系数据库 之路, 不仅自己是应用面向对象的内存关系模型, 物理数据也可以存储在传统关系数据库中(目前这还是唯一的选择), 因为模型一致, 表结构也没有文化壁垒.

谢谢! 做所有这些事情都是有一个过程的, 大家一起加油!

是的, 其实妨害继承应用的不是关系模型, 而是通过 SQL 的关系数据访问方式, 而 SQL 的不可替代性是由于内存一直不够大, 所以数据库/持久应用的设计都是面向磁盘为主体存储的. 随着内存越来越大, 内存中的关系模型数据可以主要通过遍历来访问了, 实现继承就更没什么障碍了.

其实目前的主流数据库都有一定的面向对象特征了, 如果可以打开wikipedia的 Object-Relation Database 条目, 可以看到Oracle, Postgres等等都从某些版本开始已经支持这些特性了. 特别是 InterSystems Cache, 它的成功说明在关系模型上应用对象技术确实有现实的可行性.

目前性价比比较差的 单条2G服务器ECC内存, 报价不超过4000RMB, 可以用几年.
雇用一个中等程序员这个只够一个月的工资, 还不算四金补贴等等的开销.

6年前学习数据库的时候就是网络模型的面向对象数据库，概念上的进展并不大，这个概念的出现应该有几十年了。
它的强项：在对象的增删改查，级联操作上。
弱点在于：关联操作，集合处理，缺乏数学模型的支持， 还不够成熟。

基于成熟的关系型数据库，mapping，应该还算一个不错的折衷选择。

嗯, 网络模型是计算机世界的天然模型, 用来解决计算问题最恰当.
关系模型是自然世界的天然模型, 用来建模解决现实世界的问题最恰当.

但是人们一直认为 关系模型 和 对象技术 有冲突, 也很少意识到大家其实仅只是在 网络模型 上应用对象技术.

而实际上, 用 OO 方法完全可以实现关系模型, 根本不必映射.

只是对象关系模型更依赖于大内存(也能更有效的利用大内存), 64位寻址空间的普及和内存条的成本降低让它成为更优的选择.

不是计算机模型和自然界模型的问题，
主要的问题是在数据的集合操作上，
关系型数据库有完备的数学基础来解决集合操作问题。
网络型数据库没有，数据之间的关联性体现在类的关系上，对超出类关系外的数据关系很难处理，或者说能处理，但性能非常差。这些还都是处于探索阶段。

这两天找资料又有新发现, 原来发现 对象-关系阻抗失配 的问题出在 SQL 而不是 关系模型 的不止是我自己.

C. J. Date 和 Hugh Darwen 提出的 The Third Manifesto http://thethirdmanifesto.com (第三宣言?) 分别在 1998 年和 2000 年发表了两版真正关系模型数据库管理系统的基础分析, 并且提出了同时兼顾关系模型与面向对象的 D 语言.

不过他们选的途径是很长远的, 走的是定义新的计算机语言的路. 兼顾 关系模型 和 面向对象 的计算机语言其任重道远, 从两人目前还仅只是定义出 Tutorial D, 一个面向研究教学的 D语言 子集, 而对工业化的 D语言 前景还只能揣测和观望的情况上, 可见一斑.

相比之下我走的是实践摸索的路子, 是从现有通用工业化的Java语言入手, 并且先构架开发出一个能稳定支持大型持久应用的数据库产品, 再总结其中的原理, 开辟一条给 已有通用的面向对象设计语言 加入 关系模型 优越性的途径.

看了半天，满篇都是高深的术语，除了广告，基本没看懂，惭愧。

特别不理解的是：“在内存里建立关系模型的对象数据!”，这和使用hibernate等ORM到底有什么区别？数据持久层难道是放在磁盘上运行的么？而且，我们所说的内存，一般都是指RAM，在里边保存的数据，迟早是要放到磁盘等能够持久保存数据的介质上的，难道这也能成为OO和关系型数据库的本质区别么？

总觉得，要解决这个问题，还是要从数学理论入手，在数学理论没突破以前，ORM是绕不开的。

从实践入手，恐怕，真不如号召现有的数据库提供厂商都自己实现hibernate，把hibernate作为数据库的lib，让hsql成为面向java程序员的sql。

包括 Hibernate, EJB3 JPA, JDO 在内, 当物理存储是传统关系数据库时, 它们都是使用 ORM 概念和技术, 而无一例外的是实际支持 网络模型 的应用程序 POJO 对象, 所以现在的 ORM = OO的网络模型

而实际上之所以关系数据库在整体上胜过网络模型的对象数据库很多, 关系模型 是非常大的重点, 更贴近自然世界的信息结构, 也有更大优越性. 所以基于 网络模型 的现行 ORM 方案有很多 关系模型 既已解决的问题, 不脱离目前的 ORM, 就没法完满的解决这些问题.

但是关系数据库一直不能很好的和面向对象语言无缝衔接, 现实情况并不像90年代初人们所总结的那样是对象技术和关系模型之间存在 "阻抗失配", 而罪魁祸首其实是 SQL. SQL 只能体现和利用 关系模型 的一部分, 而并非整体. 这个情况在 第三宣言 里分析得比较透彻了.

现在的情况并不是数学理论缺乏突破, 关系模型早在 1970 年就提出成型的数据管理应用方法了. 只是做对象开发的领域, 特别是对 ORM 来说, 大家一直没有意识到自己其实一直局限在 网络模型 上, 也没有怎么感觉到关系模型在 SQL 以外的应用方式.

我从实践里摸索出来的是一种 以内存关系对象模型为主, SQL为辅 的面向对象的关系数据库和应用开发框架, 比如 WoW 中的权限校验处理, 它能在 1ms 内处理相当于上百条 SQL 语句的逻辑判断. 相同的问题用纯 SQL 操作当然不现实, 如果用 ORM 的缓存来提高效率, 也还是会慢几倍, 因为 TOB 应用所访问的是直接关系模型的对象拓扑图, 根本不用复杂的缓存设计和开销. 另外如果解决复杂的现实问题, 比如用在 ERP, PDM/PLM 领域, 网络模型的 ORM 或者 POJO 有很多不自然, 平添复杂性的方面, 而关系模型就非常合适. 但是如果还是通过 SQL 定义和访问 关系数据, 那就很难面向对象的设计和开发, 这种场合是非常好的 内存关系对象模型 的用武之地. 我原来是搞 PDM 的, 可以负责任的说, 最成熟的产品都是将 SQL关系数据库 进行面向对象的关系模型封装, 只不过封装层大多是用 C 实现的, 封装出来的 OO界面 也是自家语言或者OO思想的非OO API集合. 而我现在搞出来的这个产品, 是可以用Java这种通用OO语言进行基于 关系模型 的持久应用 分析, 设计 和 开发.