举例：某公司有若干子公司，该公司管理人员需要统计出每个子公司的养老保险报表。设计如下：查询出该公司的所有子公司，每个子公司查询出所有员工，每个员工查询出他的当月缴费基数，最后统计出该子公司的缴费金额。
若员工数量较多，比如3万，是不是在代码时要生成3万个员工类，若每个员工有多个月的缴费基数是不是需实例化更多的缴费基数的类？类的实例化成本是不是很高？
面向对象的教材一般都采用很简单或涉及很少数据量的例子来讲，并且都避开从数据库中查询并实例化对象这方面的内容，我正在从过程向对象转，在这方面很疑惑。
以前，俺用一个联合查询语句就搞定了……
请各位老师都说两句，别打击一个决心OOAD的人！！！！
呵呵，这是肯定不需要di
如果像你这么设计，那么银行、电信要什么做主机那？？这要是统计一个月的总话费，或者存款余粮，估计就要死翘了。
persion.calcAccumulationFund()方法是计算每个人公积金，那么company.calcAccumulationFund()就一定是persion的累加么？？
而且从现实的角度想，你统计公司的公积金总数跟张三、李四有关系么，需要先确定张三、李四才能得到结论么，如果张三走了来了王五，两者有什么区别那？？而且使用你company.calcAccumulationFund()的人会关心你的是每个人累加出来的还是计算出来的么？？
>每个员工查询出他的当月缴费基数，最后统计出该子公司的缴费金额。
>若员工数量较多，比如3万，是不是在代码时要生成3万个员工类
当然需要避免这种情况，计算查询时可以使用SQL作为规则来实现，对象化不是简单的数据对象化。可以结合SQL语句，但是不要让数据库来影响业务层。具体可见jivejdon3的查询代码。
是这样的每个人有一个帐户，帐户中有此人的缴费基数明细，缴费基数明细是以月为单位的，如2007年10月1000元。所以公司的总额是由员工缴费基数累计的。我不想引入公司和缴费基数明细的关联，所以才有此疑惑。
如果company里面没有需要对具体人进行操作的，可以基本不需要跟persion发生干练的。
问一句：你统计公司的养老金报表时，还要给出每个人的明细吗？不需要吧，只是给出统计结果就行了。所以不需要对应人员表实例化。
是否可以设计一个统计结果类（不是对应真正的人员数据存储表，而是对应一个SQL联合查询语句结果－－查询人员表的缴费额），这样一个类方法就可以拿到结果。
我也是一个初级OO，不是是否靠谱。
[该贴被arli于2007年03月06日 21:36修改过]
如果用sql查询语句来做，为了提高效率就需要在缴费基数明细表中添加单位ID的字段，这样映射到对象上是不是增加了单位与职工缴费基数明细的关联？原先我的设计中这个关联是不存在的。面向对象是不是需要付出性能的代价呢？注：职工数量比较多，有几万。
类似的问题肯定困扰这许多的OO初学者，请高手多多指点。谢谢大家的回复。