公司已争得火花四溅了,请各位高人裁决,尤其希望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公司的,一般都是这种模式,以确保系统性能。面向对象普及这么多年,为什么在大型系统中始终不能得到应用呢?我真的疑惑了。