O/R Mapping是末，OOAD是本

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

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

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

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

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

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

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

OOA可以如此，OOD则是另一回事。同时我不认为OOAD如此轻松。经过
深刻思考和大量实践，OOAD才有可能是一项乐事。
OOAD并不接近于人类思维习惯的抽象逻辑分析方法，OOAD接近自然本身的事实。