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

我支持potian的观点。实际上在这类问题上有所倾向和争执，往往和每个人的实际项目经验有关系，如果真要上升到抽象的高度来讨论数据建模好还是对象建模好，就会发现他们谈论的范畴并不一致，大家都在各说个话了。

主要面向业务领域的项目，对象建模是首选的，在这种情况下采用数据建模会造成上层应用程序非常高的耦合性，而且业务一旦变更，整个底层(包括数据库层)的修改量是非常可怕的。我现在正在给一个这样的项目做一些技术咨询，准备完全重新以对象建模来重写，原来的系统是数据建模的，运行1年以后，问题越来越多，每次业务出现变更，底层的修改非常可怕。维护非常困难。


就一个业务领域的软件，以数据建模为中心的做法就是从需求分析到设计数据库结构，然后根据数据库结构设计软件结构，再编码，但是从需求分析到数据库结构之间有重大的鸿沟，除非那种业务非常稳定，数年不会发生需求变化的应用，你才可以这样做，否则就会造成我前面说的问题。而且你的数据库结构一开始不可能设计的完全合理，这样就会造成项目开发过程中反复修改。

前面也有人提出一个问题，就是ORM开发过程快，但是sql优化方面不足，目前确实如此，所以我也觉得在对象设计阶段，主要是设计实体类的时候，可以考虑适当的属性冗余来提高数据库查询性能。

对于对象建模的价值又了解了不少。
但，有一个问题是我们必须要面对的－－数据存储在哪里？或许OLAP不是关系模型，但，它使用的数据来自哪里？
只要我们还在使用磁盘保存我们的数据，换句话说，主存储器和大量数据存储器之间的速度差距仍然很大，那关系数据库就不太可能推出主流地位。数据库慢是慢在外排序，是慢在把数据读入主存－－简单地说就是I/O吧

即使上层的技术多么吸引人，但我们还是受到了底层实现的影响－－底层的硬件限制就是我们想象力发挥的舞台，舞跳的多好，也不能超出舞台。

事实上，软件工程师是受制于电子工程师的。虚拟机的概念一早有之，它的实现也有不少，但为何直到JAVA才取得成功？因为硬件的性能上去了。

只要关系数据库存在，对象建模和关系建模的讨论就不会停止，不是分个高下，而是讨论在何种情况下使用何种技术，如何降低混合使用两种截然不同理念技术的难度。

现在说放弃关系数据库还早，只要它存在一天，我们就要去适应它。
接受它，就要为它改变。

呵呵，说起“对象建模”还是“数据建模”，很多人就会问到底哪个重要，哪个不重要？好象一个复杂的系统可以只做“对象建模”或者只做“数据建模”一样。这纯粹是术语所带来的误导（很多人喜欢争论 a vs. b 这样无聊的问题，就象现在体育媒体热炒的 xx 德比一样），以前我也有这种倾向。
我重新思考得到的结论是，Ofbiz 并不是以数据建模为中心的，这会使大家一听就以为它是个落后于时代的东西（虽然也许你从来没有能力设计出这样一个有用的框架）。Ofbiz 中使用 Entity Engine 对数据库进行了建模，一般的应用可以完全使用 EE 提供的 API 来实现，持久性由框架自动帮你做了。所以你在 Ofbiz 中做开发可以只考虑对象的设计而不必考虑太多数据库的实现细节。从这个角度来讲，Ofbiz 是以对象建模为中心的，它的对象建模并不比 EJB 差多少。Entity Engine 只是 Ofbiz 中的一小块，因为它和 Hibernate 有可比性，所以在这里经常被讨论。你如果真正理解了 Ofbiz 能做些什么事情和如何实现的就不会认为它只是一个以数据建模为中心的框架了。我认为 potian 把 Ofbiz 理解为以数据建模为中心是有偏颇的。

设计良好的数据库应该可以适应尽可能多的业务变更。我们的框架有一套核心的数据库设计，这套设计经过了多个大项目的考验，已经很稳定了，几乎不需要做修改就可以适应各种业务的变化。设计这样的数据库需要有多年的业务开发经验才行，这是我所敬重的一位朋友设计的。在这样的数据库设计基础上我们做对象设计相对来说是比较容易的事情（一年多前我认为设计模式是高深的东西，现在我和 potian 的看法相同，这只是基础的知识。而且过度设计所造成的危害早已有 Martin Fowler 等大师讲清楚了）。如果数据库设计都没有做好，对象建模是无从谈起的。不知道有没有人考察过 SAP 的数据库设计（我的一个朋友做过这件事），它的基础数据库表打开后可能你根本无法看懂，因为这些表中的字段几乎是与业务无关的，不知道要经过多少层抽象才能上升到业务的高度。我不相信 SAP 的数据库设计是完全从对象建模展开后依靠简单的 CMP 或其它什么持久性工具生成的，它显然是精心设计的结果。SAP 要解决什么问题？企业所关心的广泛的业务问题。你能说 SAP 没有适应性吗？它简直是无所不包，让你一旦拥有，别无所求。

所以我的看法是数据建模是基础，对象建模是使应用具有更大适应性的途径，两者不可偏废。

关系数据库将在很长时间内存在下去，因为关系模型的存储和检索效率最高，理论最成熟，象层次和网络型的数据库被淘汰很多年了（但随着OLAP的发展，现在慢慢有复苏的迹象）。我们就是利用关系数据库的高效加上OO的易扩展来实现双赢。

我这里只是谈它的EE,其他不论。在EE里面，如果要持久Project这个对象，整个程序里面都看不到Project这个对象，更不要说有Project.addComponent(XXX)等等了。而都是ProjectManager.add(GenericValue value)，这是标准的数据+过程。这是标准的数据建模


开句玩笑，敬重我的人也很多 没有一个好的软件是纯粹设计出来，而是演变出来的。如果对象的设计以数据库设计为基础的，我敢说你的设计一定有问题。
SAP的设计不见得有多好，那是70、80年代的产品和设计，况且他们也在不断的发展之中，没有一个软件是无所不包的。（可以说它里面也有很多垃圾，因为工作需要，我不但看过SAP的所有数据库文档、QAD和PBCS的数据库结构都仔细研究过）
即使它是无所不包的，它也不是适合于所有用户的，我们的目的是为用户提供合适的产品，用户不需要太复杂的东西，能完成业务的最简单的设计和实现才是最好的。所以要求可裁减、可重组、可扩展。仔细看看那个最典型的Praty模式，如果你给一个用户他根本不需要的一个全能的Party模式，不累死它才怪呢。面向对象的目的不是通过静态的复杂的配置，而是通过动态的合适的重组，面向数据的系统往往在数据库中设置了成千上百的参数，通过ifthenelse这样的方式进行组合。（所以SAP有那么多所谓的实施专家，专门教你如何配置）。这是我们以前准备863的一个课题，不过最后没有批准。




这也是我想说的事情，使用O/R mapping最关键是开发方法。我推荐的OR奠基论文就已经谈到这个问题了。
你以什么样的方式去看待这个世界是最关键的，是以行为决定你的数据和相关的状态，还是以数据来决定你程序的行为。
对业务本身来说，应用程序的目的是为了实现用户的行为，所有的存储就是为了这种行为服务的。另一方面，这些对象的行为产生了一定的痕迹，我们需要对这些痕迹进行统计和分析，这一部分不太适合用对象模型。
所以如果你的程序就是一个对现有的数据进行分析、挖掘，那面向对象确实不合适。而如果你的程序是去实现业务，那么面向对象就是利器了。也因为我们最后还是需要分析数据，所以一个好的OR必须提供面向数据（或者说是纪录）的接口和查询方式。至于OLAP和其他，则基本上和我们讨论的不是一回事。


讨论这么多，最后我想说的意思就是不要把O/R mapping仅仅用作存储数据用的工具，而是应当作为能够帮助我们弥补对象/关系裂缝的粘合剂，能够让我们任意发挥OO的强大能力而很少尽量少考虑后面的问题。（AOP进一步从横切的角度把其他和核心业务本身无关的其他业务如安全、日志、调用存储（如调用OR的接口）、remote等等进行分离）。如果你本来就不认为OO能够帮助你更好的解决问题，那么使用ORM是没有任何意义的。
在一种没有O/R框架的语言里面去进行面向对象编程是一件非常痛苦的事情。如果你真正受过这样的煎熬，要不就象我几年前一样自己去做一个，要么就彻底放弃，回到SQL，那可能会更好。[/i]

>>不要把O/R mapping仅仅用作存储数据用的工具，而是应当作为能够帮助我们弥补对象/关系裂缝的粘合剂，能够让我们任意发挥OO的强大能力

但这里有个问题，这样的话其实就是数据建模和业务建模分别进行，在一个持久层中使用两种不同的技术，hibernate比较不好的地方就是不留个SQL的接口，没法用存储过程，而且要是当我要用视图简化查询时，这个映射不知道怎么做。
ORM可以让我们用20%的努力解决80%的问题，可以有时会老碰到剩下的20%问题，不留一手不行啊

我还是认为你不能单把 EE 抽出来说，Ofbiz 就是一个以数据建模为中心的框架，Ofbiz 中的某一部分不是单独使用的，我从来没有想过单靠一个 EE 来做什么事情。Ofbiz 总体上重用度还是很高的。

我基本上被你说服了。争论的焦点是搜集到需求后先做对象建模还是先做数据建模。我现在也基本上同意应该先做对象建模，因为既然数据库设计肯定是要改动的，那么可以把这部分设计放到最后，等对象设计稳定下来（得到了一个原型）后再考虑，这样改动就会比较小，成本也比较低。修改数据库设计的成本在最初的原型开发阶段并不高，只是在进入大规模开发保存有大量数据后才比较高（因为要把这些数据转化为另外的格式）。这个思路是合理的。
但是你的开发服务器不可能 24 小时开着。你还是要有一个地方将数据持久保存，以便验证你的设计的正确性。你可以不存在数据库中，而存在文件中或者直接通过对象序列化的方式保存。
按照我的理解，对象建模实际上可以分成两个层次，分析阶段和设计阶段，所以有分析模式和设计模式之分。数据库设计（数据建模），要放到设计阶段之后来进行。

OLAP 我们也要做的，目前这个 report server 就是基于 OLAP 的，在这里 OO 并不是非常重要。
《Analysis Patterns》正在读，等过些时候读完了再做深入的探讨。
Good luck!

非常同意，说到我心里面了。我现在做的一个项目就有这样深深的体会，如果不让我用ORM，我就必须彻底放弃OOAD，而改用数据建模方式。而用数据建模方式，我不敢用，因为风险非常高，一个系统在开发阶段和使用阶段，都会不断遇到要对系统某些部分进行修改的需求，就是在开发阶段本身都会有很多次迭代，没有任何一个人敢说他可以在编码之前把系统设计的完美无缺。而采用数据建模，程序对数据库表的依赖性，耦合性非常非常高，做到一半，发现有些数据模型需要修改的时候，一改就是大改，程序大面积修改。

总之，如果你是OOAD，不让你用ORM，那是非常痛苦的，要自己写持久层框架；如果根本就是数据建模的设计思路，那么用ORM对你来说同样痛苦，我会劝你还是用SQL，或者用iBATIS。我在论坛里面就看到过关于Hibernate的问题的很多帖子，思路都是数据建模的思路，把Hibernate用的很痛苦。我想忙完手上的事情以后，搞一次聚会，和大家好好交流，也把我完整的OOAD设计思路，实施步骤，技术框架做一次全面的介绍。

>>我想忙完手上的事情以后，搞一次聚会，和大家好好交流，也把我完整的OOAD设计思路，实施步骤，技术框架做一次全面的介绍。

要录音啊！
估计是在上海搞的啦，我可能没机会当面向各位老大学习了

我觉得在企业级应用中如何使用好各种模式、框架，侧重于对象建模还是侧重于数据建模，主要还是考虑一个经济问题。
Hibernate 这类 ORM 框架减轻了修改数据库的代价，使得设计人员脱离了数据库实现细节的桎梏，而真正从对象和业务的高度考虑问题。这才是真正的软件开发。软件开发就是应该与具体的工具脱离开，成为一种纯思想的实现方式。
如果没有 ORM，想要不考虑数据库设计是非常困难的。

这20%也可以自已写JDBC来实现,  Hibernate不做, 我想是因为涉及到PO与DB数据的同步问题, 留个SQL的接口, 做不好同步问题,说不定被别人骂得死去活来, 做好了性能受影响, 对Hibernate也不是好事,权衡利弊, 我觉得现在Hibernate的定位是正确的,Hibernate只是一个简单的ORM, 象CMP那样做的复杂了, 提供远程访问能力, 安全问题等(这些与SessionBean重复了), 但ORM本身却做的不好, 这样反而跑题了.

现在Oracle发展的Object-relational  DBMS(ORDBMS)  底层用表存储, 跟现在的ORM是一样的, 不一样的是, Oralce 的 ORDBMS中的object, 只限于在oralce这一层使用object, 跟我们在应用程序中使用的OO中的object是有区别的.  我不是太清楚oracle worlds中的一大堆东东, 象oracle form, oralce report等, 也许它们都可以使用ORDBMS中的object, 但我认为如果要用Java, C++, C#等OO language, 在Oracle 的ORDBMS是行不通的.