O/R Mapping是末，OOAD是本

问题集中在以下几个方面:
1.数据库由他们设计，他们不习惯用逻辑ID，喜欢用业务主键。这也还好，可是他们还喜欢用组合的业务主键。开始时，他们尝试使用逻辑ID，但后来终究以不能适应告终。

2.喜欢在一个表中存入关联表中多个字段，而不只是关联主键，说是为了提高查询效率。而我建议到后期进行查询的优化，尽量花小的代价保持数据一致性。

3.在第2个问题中，也有因为业务需要保留历史记录的，所以存放关联表中的多个字段。
例如：在交易表中记录帐户行编号同时记录帐户行外部帐号和内部帐号。本来我想剔除后面两项，只用帐户行编号来关联。但他们说有时帐户行信息改变了，但是查询统计时又希望看到当时交易资金流向的实际帐号。
这个问题不知道怎么解决，我总感觉是需求出了问题，可能是需求上应该进行更细致的分析。

不习惯用OO方式思考，没有对象建模，直接就是数据库设计。例如信用证LC，我觉得应该抽出来作为一个对象，而他们直接就是设计开证信息表，将信用证信息和其他业务信息混在一堆。
想想他们那时用DELPHI开发，大多就是先搞搞需求的分析，然后就是画出功能界面，然后针对界面弄张表，存放界面填写的数据。然后写函数，设置到事件触发。
现在的旧系统还是能用的，但是所有的开发人员都在外面维护或做二次开发。一旦碰到某点需求的改动，动不动就是一帮人在外面弄几个月。

我原来在沿海地区搞开发，现在在内地搞开发，感觉两地的程序员思考的方式完全两样。一阵痛苦的沟通之后，他们认为问题出在hibernate身上，所以要放弃hibernate，改用JDBC。我觉得问题并不在hibernate身上，而是OO的问题。即便用JDBC，我想还是会碰到上面说的问题。现在我已经放弃了，因为势单力薄，你觉得有办法说服他们么？

对着一堆没有OO思路的人，你就是对牛弹琴。我现在碰到这种人，根本就懒得和他们纠缠，直接劝他放弃Hibernate，改用JDBC，或者iBATIS。

一直也想提这个建议  在javaeye论坛潜水也快半年了 一开始只是对hibernate好奇 后来越来越感觉 对ooad非常陌生 于是就在论坛里翻来翻去 找一些各位大牛讨论设计的帖子(收获非常大) 但是总觉得缺少一个完整的设计 一些概念或者说是想法 也总是模模糊糊的 感觉要做一个好的ooad是需要很多经验积累的

在google里搜过好几把 也没有找到合适的例子

非常希望能开辟这样一个样例区 让我这样没有经验的小鸟 能有个长见识的地方

不好意思小弟刚刚接触oo和java
http://www-900.ibm.com/developerWorks/cn/rational/oo-design1/index.shtml

举双手赞同,希望那些习惯了关系数库的DBA们,也好好学学OOD,那真是我们做上层应用层程序的人的福[color=olive][/color]

我的水平很差,但还有比我更差的..而且死不悔改.痛苦....

面对以DBA为首的系统分析员，又能如何作为？

所以你要让他们接受你的观点，除非你用你的客观数据来证明他们观点有些问题
比如，他们说的所谓性能问题
他们说的所谓方便性问题
如果能够拿得出数据来说明问题，
你又能把理论问题解决了，
估计人家就会听你的了！

实际上感觉上这个问题
更容易让我想到
军队中正规军和游击队的区别
正规军接受了长时间的正统的OO思想教育
理解并知道OO的优势弱点在哪里
看中OO与实际项目经验的结合

而游击队没有受过OO教育，更在乎手段，
往往喜欢根据以往的经验判断
这样的话接触OO的时候也只是很片面的理解

另外我绝对所谓OO也绝对不是最靠近人类思维的方式
人类思维方式好像跟接近XP，这类一点点积累一点点重构。而不是从某个层次开始就把整个系统都设计都OO化

我也在努力提高OOAD的能力，推荐一些书给想在这方面努力的朋友们：

UML和模式应用
分析模式
Objects Model（影印版）
ColorUML（电子版）
领域驱动设计（电子版）
敏捷软件开发-原则模式
数据资源建模手册
UML业务建模