DB设计人员与OO设计人员间的冲突

说的是
就好像俺们的不分工
一个表里面的字段有user_id,userCode,USERZIP,YHNAME……

在很多企业内部会有不少遗留系统——越是大企业，越多。ORM在这些场合很难有作为。复杂的数据库，逐渐变味的系统，能用标准sql解决都很不错的了，sp和数据库专有函数大量的使用更是常见。DBA还负责数据库的调优。在这样的场合，如果使用java的话，jdbc我想是最有效的手段。如果有DBA的存在，是一件好事，访问数据库的sql可以由DBA来写，java程序员只要将查询结果绑定到对象上去。很多方法可以缓解这些工作的工作量，包括spring－－spring最早吸引我的，就是它自己的JDBC Template，那时它还没提供hibernate集成。

手动映射是最有效的，hiberante也是手工映射啊，只不过是用xml描述，外部化了。

不要指望工具能解决所有问题，只要它能有效帮助我们解决大部分机械劳动就很好了

我并没有说不需要数据库设计人员，我的前提是，“既然你要用O/R Mapping”那就不应该把数据库设计人员和对象模型设计人员分开，而应该是一种互相促进，补充设计的过程。



这个观点强烈赞同！在这种情况下，既然不用O/R Mapping了，那当然就需要不同角色的设计人员，在不同的层面上做不同的优化。

我不知道楼主所在公司的开发流程是怎么样。按照我的想法，应该是设计人员在一起共同讨论对象模型，即PO的设计，然后根据PO生成hbm和ddl，然后偏向数据库设计的角色人员可以考虑在这个基础上有什么优化的方式，反过来优化以后再看PO是否可以进行设计的重构。这样几次充分交流以后，很多矛盾都可以解决。

并行做对象建模和数据库建模，然后再做o/r mapping，根本不可能。两种建模对系统设计的看法不同，在动态模型上，对象建模以对象行为为出发点，数据库建模以对表的crud组合为出发点。
   如果以对象建模为中心，数据库逻辑模型的设计应该以理解系统的对象模型的人为主，反之亦然。
   不管是那种方式，用之则坚持，别中间路线，到时候就啥都不是;两帮人也应该互相帮助，其实很多时候一个人既可以是熟悉数据库的人也可以熟悉对象建模

我想说的只是在这样的情况下，使用SQL会是更好的选择。试试ibaits吧

至于对象建模还是数据建模，特别是并行做，这个论题太大了，我没这方面的经验，也不好乱说

O/R Mapping的映射策略一旦确定，就决定了数据库设计。
如果是一个新系统 + 如果公司走的是OO的路线， 容不得DB设计人员自由发挥，一切从领域模型中来，一切为了实现领域模型，而不是做一个让DB人员看着舒服的规范的DB

OO不OO的,是不是个公司路线问题?也不明白什么叫公司的OO路线.
有几个讲得清楚OO是什么.
我怎么觉得 OO设计人员,比DB设计人员,乱来的可能性要大得多.

我觉得这个问题,就是2波人的问题, 搞成一波人,不就解决了。
没什么路线之争。

O/R mapping搞不来的地方就加个DAO，把差异隔离起来，外面正常搞领域模型。

听起来有两种可能性
（1）系统设计人员同时进行数据库设计，一个人兼多个角色。
但是我们里的人员架构发展方向就是要不同角色由不同的人承担，尽量的做到专业化 ---- 是否说人员架构上还得再灵活点？

（2）OO设计和DB设计由不同的人承担，加强沟通。
ok，我承认，这更多的是人的问题， OO设计人员和DB设计人员都比较Sharp，都希望以自己的思想主导对方。在谁都没有权利主导对方的情况下就造成了映射上的不能实现 。这个从侧面映射出管理上的问题。 要是换了另外一个公司两拨人，可能根本不会有类似的问题。

我认为采用O/R Map，主要应该对象模型的驱动，需要在对象模型建立后数据库模型再参考并建立。可以看到这里的大部分留言也是支持这种观点的，只是不知道这样的问题，放到一个DBA的论坛里会有怎么样的回复。

没什么好冲突的，全新的系统，没有遗留的问题，以对象建模为主导，出现性能问题后再和DBA沟通——不是说系统上线后，而是表结构出来后，一个DBA已经能够评估可能出现的问题了。测试，确定问题的根源，把它隔离开——OO的另一项重要作用，用可能的手段解决它。

如果有遗留系统，要么推倒重来；要么，DAO+SQL，没什么好说的。

ORM适用于OLTP(大批量的数据插入和更新恐怕也成问题，不过出现这样的问题，那是无论怎么做都是麻烦的，那主要是数据库的错)，以查询，分析，统计为主OLAP型应用，力不从心。

根据应用类型和项目特点选择技术。