对于一个类间继承关系复杂的企业应用

有一个这样的行业国际标准，定义了一个用于各相关应用之间进行数据交换的用面向对象概念架构起来的公共信息模型。该模型是一个以继承关系为主线的网状结构，注意：主要是继承关系。举个简单的例子吧，类似于：

人——男人——男学生——男大学生——男研究生。
水资源——湖泊——内陆湖泊——淡水湖泊。

（当然，上面提到的模型比这2个例子要复杂的多。）
现在想以这个模型为基础，进行企业应用开发。

我想问的是：在做O/R mapping时，采用一棵树一张表还是采用各个类特有的属性独立成表好？
我个人倾向于后者。这样一来，表结构层次很清晰，尤其对于这么个复杂的信息模型而言，很重要。而且，在扩展模型、往模型里添加新的类时，很方便，采用继承的方式（以树枝的方式表现出来）就可以添加进去。但是，我们的企业应用很多是查询和统计，按后一种O/R mapping方式的话，会造成大量的连接操作。以前的做法是在数据库里搞个view，提高查询时的性能。现在如果采用hibernate的话，该如何做呢？到目前为止，我还没有看到过hibernate与数据库view的关系的资料或介绍。

稍稍有些苦恼啊。

怎么，这个话题不受欢迎吗？
hoho，自己来ding一下。

我也认为应该把父子关系的持久对象保存在一张表中，既然在一张表中，哪来的连接查询？

这应该类似于RDBMS和ODBMS的差别吧。

Hibernate既然是一个O/R mapping工具，它绝对支持按照关系原理来设计数据库。似乎没有必要把一个对象继承层次都映射到一张表，这样列过多，也对简单查询的效率有影响吧？

首先要说明的是，我面对的这个模型是个非常复杂的模型（抱歉，我举的例子里表达出的各种关联关系是那么的简单）。所以，如果采用把一个对象继承层次都映射到一张表的方式，会有以下几个问题：
1）这张表的列过多——而且是及其过分的过多。实际上，模型的一棵继承关系树里，每个类各自独有的属性并不多，绝大多数情况下是不超过5个的。比如：爷爷有4个属性；爸爸继承爷爷，并有自己的3个属性；儿子继承爸爸，并有自己的5个属性；.......。
2）类与类之间（不仅仅是在一棵继承树里）的关系复杂，包括聚合、组合、普通关联等等。用robbin建议的方法，又会要在那一张表里添加属性。
3）没有能最大程度的保留模型的OO思想。

我的问题还是：

对view进行映射呀

那就多建几个表呗，一个类一个表。除非你采用OO数据库，否则总不可能十全十美的。

那insert、delete、update的时候也就变成对view操作了哦。好像可更新view要收到好些各限制吧。

view主要是用来查询的吧。

再说，你就是用jdbc也一样有这样的问题。