数据建模 vs 对象建模 (从Ofbiz帖子切分出来的)

看来你是比较倾向对象建模
呵呵，这样就引出对象建模与关系建模的争论了
我是比较喜欢关系建模的，很简单，我不会对象建模……（别拿板砖砸我）
关系建模的基础是集合理论，而集合的研究在数学上是比较完善的，可以说，关系建模是有一个严密的理论基础。这个基础是相当简单的－－至少概念是这样。
简单往往意味着高效。
而对象建模呢？我不清楚
基于集合理论的关系数据库在处理数据的性能上是无可匹敌的，对象数据库的效率绝不可能和关系数据库处在统一水平线上。完全的面向对象数据库搞了十几年了，始终无法打入主流市场，这是一个很主要的原因。如果有面向对象的数据库，我们根本不用讨论ORM。
基于对象的数据库倒有几个，但我的看法实际就是关系数据库的底层上加一个ORM，只是这个ORM做在数据库端。

到底什么是对象建模呢？各位老大能否给我等扫扫盲？

我们当时做的是ERP，我认为MIS是对象建模最好的领域之一。看一看Martin的分析模式

我想现在已经不应该是争论的时候了，马上2004年了，呵呵。
只要你使用数据库，效率永远是低的。Do you still use database? (Prevayler) .程序本身的效率最后还是需要通过Cache（或完全的内存）来解决的。
而开发的效率和程序的可扩展性是o/r或者说OO试图解决的一个问题。
------
至于对象数据库，那是外存存储和检索机制的问题，而不是在内存中的对象模型

>>只要你使用数据库，效率永远是低的

可不能不用啊，只要用了关系数据库，肯定就会出现这个问题，不管是在什么时候

2004年有什么好的技术能解决这些问题呢？

呵呵, prevayler写入操作实在是有点慢, 我单线程的"测试"过mysql, prevayler, jisp, 它的写入太慢了, 估计瓶颈全在日志的IO上, 特别在并发的情况可能更差了, 好像是有改进的余地吧, 但是也不会好很多可能.
另外就是它的内存模型好像太少了, java的collection不是太够用, 使查询之类的太弱了, 如果有B+树这样的结构可能好点, 我尝试着写过, 不过实在是麻烦啊.

不用数据库是完全做得到的，当然现在还有限制。到google上去搜索Prevayler或者RAMDB就可以了。
OO程序的效率不一定比数据+过程的速度慢，原因是OO更能实现Once and Only Once，更容易分析问题的瓶颈，也就更能优化效率。效率的优化不是在100%的地方优化，而是在20%的地方优化。--举个实际的例子，OR Mapping一般比你手写的程序效率高，因为在一个ORM产品的发展过程中，它只需要在几个有限的地方，针对某几个有限的影响效率的地方进行优化，而一般手工编程需要在很多地方进行优化，并且没做一次都要去手工编写，手工维护，手工优化。OR mapping则吸收整个社团的专家知识，不断地重用和进步。
退一步来讲，就算你是一个非常高的数据库编程高手，你写出的代码比O/R的效率高，你不能保证每个地方都可以这样，你也不能保证每个人都这样。而软件项目是团队工作。
OO的重要作用是程序的可扩展性、稳定性和适应变化，以及使用面向用户的语言和概念分析问题和解决问题。这是比你在数据库存储提高5%（如果有的话）更重要的效率和优化。
2004年还在谈论数据建模和对象建模的优劣，我想对大多数程序来说是非常可笑的。这应该是1994年谈论的问题。但我不是说数据建模就没用了，数据建模照样可以解决问题。现在很多人还在用C和PB写管理系统，他们照样能够做得出好程序来。是否能够很好地实现用户的业务是最终的。只不过2004年我已经不太愿意到邮局去寄信，而是愿意用email发邮件。
OFBIZ这样的整合工具，用在小规模的系统里面还是很有优势的。

是吗，我倒没有遇到你这样的情况。
在内存里即使用单纯的顺序迭代也比数据库查询快，而大多数缓存的原理就是一个HashMap.
对比一下read/write cache+database和Prevayler，如果前者比后者快，那么只能说明Prevayler本身的实现有问题，而不是说没有改进余地了。
--------------
看到你在这里，我来聊一下，呵呵

我测试的是写入数据(不是读取数据,读取肯定它很厉害),就是prevayler必须把事务log下来,它的log太慢的,如果换成java NIO之类的也许好点,不过好像2.0版出来了,还没看过.
PS: 这里大部分都东西我都插不上嘴:-)

我索性多说几句。
抽象层次、可扩展性和可读性对解决问题的重要性不言而喻。为什么我们现在都要用SQL语句存取数据库，这样的文本传输效率不是很低吗，还要DBMS接收到SQL还要解析,数据库厂商干吗不直接开发底层的API（不用SQL的API)让我们来调用数据库底层操作。
这都需要权衡的，我不是很相信一个大的项目采用数据建模+手工SQL语句编写效率会比一个好的O/RMapping效率高。就象我不相信一个人用底层的数据库API存取会比Oracle解析和优化SQL执行效率高一样。效率是可以通过各种手段解决的。特别是有好的抽象，就会有提高效率的可能性。并且绝大多数情况下，抽象好的程序效率就是比抽象差的程序性能好。因为没有抽象，往往是捡了芝麻，丢了西瓜。
我经常看到以数据为中心的开发方式最后产生的数据库极其冗余，基本上违反了每一个数据库的基本范式。我也经常看到很多数据库的设计连个基本的OID都没有，从何谈效率。我也经常看到数据表之间基本上没有约束，从何谈数据的完整性。这些问题并不单单是因为设计的问题，很多情况下是因为系统的演变造成的。而这是数据建模比对象建模弱得多的地方，也是为什么传统应用程序维护成本高的重要原因之一。
事实的情况是，好的O/R Mapping不但没有降低数据存储的效率，而且迫使绝大多数的程序员遵守数据库设计的基本规范、更加符合数据库的基本理论，数据之间的连接速度更快。

呵呵，这些话很容易引起争论的，我们还是平心静气地多探讨探讨。
我觉得只要能很好的解决业务问题，无所谓数据建模或是对象建模都是好的。其实很多问题好的数据建模完全可以解决。
“数据建模”这个术语我的理解是非常模糊的，我把针对数据库所做的设计都认为是“数据建模”，所以 OLTP（O/R Mapping 也属于这一类）是数据建模，数据仓库、数据挖掘、OLAP 我觉得都是数据建模。可能 potian 兄还有更精确的定义。
我并不认为对象建模可以解决企业面对的所有的问题。比如数据仓库、数据挖掘所要解决的在企业的海量数据中成功地获取信息的问题，我并不认为对象建模可以很好地解决。数据仓库、数据挖掘的经典教材中我也看不到什么与对象建模有必然联系的东西。
所以千万别小看了这个“早已经过时”了的数据建模。potian 兄是不是有点“万般皆下品”了，呵呵。

其实我说这些话自己都感觉有些背时。
并且我现在根本就不认为OO是上品。只能说是基本技能了。
数据建模我说的模糊了一点，我说的基本上是应用程序开发中的面向关系的数据模型。OLAP不是关系模型，是多维的，事实上基本上不需要程序开发。不过不是我杜撰的，应用程序本身开发的模型根本就不谈这些东西（看一看《数据模型》和《分析模式《这两本经典的书就知道了）。