公司已争得火花四溅了,请各位高人裁决,尤其希望bang参与

系统设计中遇到如下问题,公司技术人员争论得十分激烈,各执一词,十分希望高手裁决之。我们公司技术人员都十分关注这个贴子:

1、采用代理主键作外键,还是代码code作外键
表1:代理主键——id,并取代码作唯一约束——code。
表2:参照表1时,其外键应参照code,还是id?
在这个问题上,有三种策略:
1)参照表1的id。优点是明显的,缺点是查询时必须进行表联接,尤其是有时需要对代码进行模糊查询的时候更是如此。
2)参照表1的code。优点是对代码进行模糊查询时不需进行表连接,缺点是code不能发生变动,否则将同步修改很多相关表。据说这是很多大公司的做法。
3)参照表1的id,并冗余一个code字段。同时具备第1、2条的优点,但也具有第2条的缺点。这种做法似乎很常见。
我个人认为应取第一种策略,对于确实影响性能的,经过分析后可以采用第三种策略以避免连接,优化性能,但无论如何不能采取第三种策略。

2、数据库视图的使用
有三类项目:类型A,类型B,类型C。这三类项目都有一些公共的特性(比如地区等信息。需要对面向全部项目统计查询),大约占字段总量的50%左右,这些公共特性经常需要在查询中用到。在数据库设计时有如下策略:
1)三个分类项目表+一个视图:三类项目分开建表(表:项目A,项目B,项目C),这样给项目的操作上带来很大便利,但同时给查询上带来了不便,要从所有项目中查找数据,必须参照三个表。为解决这个问题,从三个表中提取了一个视图,相当于 项目表。
2)一个项目表+三个分类项目表:建一个项目表,再建三个分类项目表(表:项目A,项目B,项目C),共四个表。这样给查询带来了方便,但给增加和修改操作带来了麻烦,这时必须修改两个表。
3)冗余策略:建一个项目表,全部属性设置在一个表内。这种策略给查询带来了方便,但增加操作却非常麻烦,必须把每一类项目要设置哪些字段弄清楚。
我比较看好第一种策略,这种策略在完全不冗余的情况下,实现了查询和增删改的简便性。但听说现在不推荐用视图,所以有些犹豫。

另外,我们目前虽使用hibernate,但完全是使用的单表模式,即没有建立一对多、多对多的关系,全部是针对一个表进行的操作。并且公司一位从大公司出来,并且很有经验的高手说,一般大公司,尤其是做ERP公司的,一般都是这种模式,以确保系统性能。面向对象普及这么多年,为什么在大型系统中始终不能得到应用呢?我真的疑惑了。

>面向对象普及这么多年,为什么在大型系统中始终不能得到应用呢
不能一叶障目,轻易下这个结论。

本人搞对象多年,对你们争论这个问题已经疏远,完全不是OO设计层面的问题,而象是在争论使用Linux还是windows等细节问题。非常对不起,应该贴到ITPUB之类数据库论坛去吧?

推荐一个正确使用Hibernate方式:
http://www.jdon.com/article/31684.html

1.使用code做外键:必须code能有实际意义,并且在系统部署后基本不会变更。
2.可能我没怎么理解好,我只是想说:如果A、B、C三个对象都有一人共同的属性X,一般来说,就分别对这三个对象的属性X进行编程,而不是对他们共有的属性X进行编程。

我以前也考虑过这个问题,我是如下考虑的
id主键其实是基于数据库层面上的,在DDD的时候,业务实体是不具备id属性的,他是因为关系数据库的关联而存在的。
id就好象是一个人的DNA一样,用于还原对象时进行标识,我认为还是用id好,我也一直是使用id的。至于code那是因为有业务需求而存在的。
业务实体间的管理是通过包含其他业务实体的关系存在的,所以id主键这个东西只存在于持久化对象上,而业务层是不出现持久化对象的,只有业务实体。这也就介绍了了业务层与持久层的耦合。