面向对象建模与数据表建模两种分析设计方法的比较的思考

不好意思，我又来发布一点不同的声音了
1、为进一步说明OO和关系数据库是属于两个不同世界观，存在天然矛盾，就象有神论和无神论。
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
从本质上两者是和谐同一的，为什么这样说，因为你所有对象的属性最终分解的结果不会超过计算机固有数据类型，即int，char，byte，double，float等这些基本数据（现在string也算基本数据结构吧）db完整的实现了这些数据结构。而且OO与DB很多地方相似，比如对象的完整性（一个对象必定要有固定的属性，且要保持数据完整，DB的需要有固定列，而且强调数据完整性），对象的可扩展性（对象的继承，子类比父类多属性，DB是新的表）。

2、对象和关系数据库累赘转换
－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
这一点我承认，确实是存在一定的麻烦。但是我又仔细想了一下，好像有那里不对。那里不对那？？就是对象的序列化问题。网络传输，对象存储，都会要序列化，当然现在说最符合思维而又让人能够很容易看懂的最好方法是XML。如果使用COBRA，EJB也许可以不用关心网络传输的序列化问题，但是存储的序列化还是要考虑的。xml最大的优点就是最大的缺点，自我描述的冗余性。且效率上存在很大的问题，而且需要自己来保证数据的完整性，依然很麻烦。

怎样解决：
public class Course {
　　public string name;
　　public int courseID;
　　int deptID;
　　public int creditHours;
}
这样的一个对象对应一个表行的可以使用反射，增加一个属性对应数据库增加列，可以要求名称具有特定规则即可（Java的规范便是这样的约束）。
关于人与学生的那个，应该使用多张表来解决。而且现在也是这样解决的。国内某家银行，其对公对私客户是放在一张表中（统称客户表），根据对公对私的不同特性会有不同的特性表。从数据库方向考虑也不推荐放在一个表里面，会严重影响效率。
关于教授与部门的，是采用映射表的方式，代表部门的是部门ID，代表教授的是教授ID（OO也是这样的，怎样找到一个对象？？通常我们会通过ID来寻找）

Hibernate只能解决简单系统的问题，不能解决所有问题，当系统复杂，OR映射时需要自己写代码（OO的序列化也得自己写，干脆序列化到DB），而且是否一次性提交那么多数据，在于你可以适当考虑充血模型（setter里面只对修改属性进行记录，提交时只修改变动属性相关表）。

综上所述：DB与OO并不是天生的对头，而在于你怎样去看待这两个工具。

－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－
是在是原来的讨论贴不让我回复了，只能新发了，纯讨论，勿删贴