对象之间的关系的疑问

hibernate比之一般的SQL-OBJECT MAPPING框架的优势就是能实现对象之间
各种关系，开发者可以完全不了解SQL结构的情况下使用hibernate操作数据。
我的疑问是，这样的关系是否有实际价值？
从逻辑上看，我常常需要从一个对象找到另外一个对象。比如从部门信息找到
部门所属的员工。但是在实际开发过程中，我还是老老实实的用SQL/HSQL去找
原因如下
1。对于查询而言，使用hibernate自己带的one to many性能太低了，虽然可
以使用lazy load.但是对于一个有几千个用户的部门，或者更多，几十万（比如
交易记录），这样的简单查询时没有意义的，必须作分页处理。另外在某些字段
比较大的情况下，这样的处理更加恐怖，需要使用抽象分成父/子类关系i。
2。对于批量更新而言，比如给当前部门所有员工加薪的操作，显然还是用SQL更
加有效。
3。对于及联更新，比如追加一个家庭，连带素有的成员，其实也可以简单的用
方法封装以后实现。比建立影射关系还是简单一些。
4。如果引入DAO,考虑到以后的移植，比如从hibernate到jdo,ejb。这样的简
化关系还是应该放弃
我至今基本没有使用各种对象之间的隐射关系的机制。虽然看到了一些解决方案
但是总体上还是比较困惑，欢迎各位大牛菜牛指导

1、

几千个用户，没有那么慢吧？
可以把您的测试用例贡献出来观摩一下吗？

大的collection确实可能有性能问题，
比如Company和Employee是单向的one-to-many，Company中有一个Set类型的属性employees，当你要添加一个Employee时，要这样
company.getEmployees().add(employee);
...
这将导致整个Set被载入（如果还没有被载入的话），如果这个Set很大，那性能就很低。

即使你为这个Set设置了cache，add操作也会使这个Set变成dirty，在下一个Session中再对这个Set操作的话，又要重新载入它。

使用hibernate自己带的one to many性能太低了

刚才认真看大牛推荐的对象模型和数据模型的贴子，没错，其实我的疑惑就是这个。一般来说，我们都是从传统的数据模型为导向相的业务开发人员转向过来的，所以不可避免的有着这些类型的困惑。
在此之间我一直使用自己开发的一个类似ibatis这样的SQL -MAPPING工具作开发，更早使用过ejb.
现在对hibernate使用只是一个小规模的参试也只是在项目的很小一部分是用了。虽然了解了hibernate这方面的能力但是还是心存疑问，也因为风险，尽可能的没有使用。
使用sql mapping这样的结构作开发的一个实际问题就是如何应付业务的变更。
一当需求变化必须修改多个地方，值对象,sql mapping文件，数据表，页面、
教研逻辑，统计报表。虽然可以使用工具来节约一定的工作量，当依旧是恐怖的。好处是在开发人员都熟悉SQL的基础上可以轻松简单的做业务开发，前提
是需求变更比较少。
在我转向使用hibernate/castor这样的o-r mapping工具以后，其实思路依旧是一样的，我发现除了解决了跨数据库的问题，并没有本质解决我的问题。
所以提出这个疑问。
我还有下面这些问题。
1。如果按纯正的对象建模的思路来考虑问题以后，对HSQL怎么处理？使用
HSQL来完成对象检索、更新操作就不可避免的有个问题，业务对象发生变化以后，需要全面维护这些东西。举个列子，我对某个属性名称进行重构，而在数个HSQL中引用到这个属性，维护还是存在一定工作量和风险。当然了，可以通过强调自动化的UT来解决，可是总还是觉得少了点什么。
2。同上的情况下，我还是避免不了界面、教研逻辑、数据报表的变更，在和工具正和的比较好的情况下，这种变更的工作量并不比我以前的做法更有效。尤其是对较研逻辑的变更，版主有什么经验教育教育我。
3。报表的问题。传统的做法，为了考虑报表和性能，实际数据模型存在大量的冗余，还不一定能完全满足要求，如果完全按此种思路转变，那么这些问题如何解决？实际上数据如果严格按三范式约束，我们的很多业务系统根本无法做出报表
或者在海量数据的情况下，有很大的性能问题，能够提供一个简明的思路？

我承认对于业务建模\ooa我是个地道的菜鸟，版主有什么好的读物可以推荐？
尤其是和业务开发有关的，能结合类似hibernate的解决方案最好。多谢了

这个问题真的是很困扰人。如果采用hibernate，数据必然被分散很多个表里面，那么统计的时候，呵呵，就有得受了——光是外键关联引起得性能损耗就得烦死你。

这几年我们做的项目，原则上都是不要物理外键的，只是程序上有逻辑控制。
主要就是这个原因

但是，如果不要物理外键而仅仅用程序上的逻辑控制的话，对于大象目是肯定不行的。一是维护度和复杂度上升，而是性能也下降。
我昨天和我的PM讨论了一下这个问题。他们曾经针对部分表进行过行列倒置的设计。
参见我的帖子：http://forum.hibernate.org.cn/viewtopic.php?t=2427

在写程序的时候，各表间的关系实际还是要代码预先作校验的，不可能扔给数据库做，抛个异常出来。开发阶段建外健，帮助发现程序的缺陷，生产环境我们就把物理的外健去掉了。
应该是外健引起性能下降才对吧？千万级的数据库，使用外健不是用外健性能
差挺大的，这是公司开发人员的实际经验。以前公司的洋博士也反对我们这样干，用范式和一致性教育我们，可是实际运行有问题。
你举的那个贴子入如果我没理解错的话，和scarab的实现是一样的。就是只有逻辑表和逻辑字段。
但是我挺担心这样设计在统计的时候得速度。详细讲讲你们的做法怎么样？