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

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公司的，一般都是这种模式，以确保系统性能。面向对象普及这么多年，为什么在大型系统中始终不能得到应用呢？我真的疑惑了。

呵呵，我不是高人，随便说说。
1、我倾向于第一种方案，即使要做关联查询，不见得对性能有多大影响；第二种方案很烦，而且code变动基本上不可避免；第三种方案不到万不得已，一般不使用，除非对性能影响特别大。

2、我比较倾向于第二种方案，可以建立一个主表，其他的A、B、C与其关联，应该不会出现同时更新多表的情况吧。主细表我以前用过很多，也没觉得有什么毛病。不知道你们为什么不推荐使用视图，是基于性能的考虑吗？

-->应该不会出现同时更新多表的情况吧。
不会。

-->不知道你们为什么不推荐使用视图，是基于性能的考虑吗？
是的。不知道目前视图在大的程序中有应用吗？

thanks

视图在大的程序中有应用

用有一定规则的流水号隐藏更多的类别信息可以放到一个表中

这种问题还是要看系统得实际情况大家一起讨论
希望达成一致

夸张.小题大做

呵呵..
1.现在我们开发的项目是应用第二种方案..用第一种方案太经常要关联查询了..第二种只是偶尔会有更新..第三种是完全没有必要了..

学习经验ing

QUOTE:

---

最初由 julyboxer 发布
呵呵..
1.现在我们开发的项目是应用第二种方案..用第一种方案太经常要关联查询了..第二种只是偶尔会有更新..第三种是完全没有必要了..

---

分析一下 表的主要用途有哪些？不要绝对的选择第一种或第二种方案

如果两者相结合，是不是更好？

更新多的表，用第一种方案
查询多的表，用第二种方案

第一种方案 到 第二种方案的 同步或转换的这个方案，应该不难吧

象Google 或 Baidu 这样的数据量查询，肯定是用第二种方案。
而他们的网页收集 是采用第一种方案。

如果不是两种方案相结合，收集网页时，他们会死，用户查询时，用户会慢死

关键是看你们的数据量多大。

-------------------------------------------------------------

关键在于你们的“度”是多少

Varchar(10)和Char(10)的区别 应该不大吧

如果这个表的记录，是上1000亿条呢？

Varchar(1000)和Char(10) 区别大吧
如果这个表的记录，只有10条呢？

自己把据“度”