主键和外键的设计原则

从MYSQL4.1开始，它终于支持了外键。在数据库设计中，主键和外键是一种能够把多个表组织为一个有效的关系数据库的粘合剂。它们的设计良好与否对数据库的性能和可用性有着决定性的影响。
不得不说的是，在系统设计的时候，必须将数据库模式从理论上的逻辑设计转换为实际的物理设计。而主键和外键的结构是这个设计过程的症结所在。毕竟，一旦将所设计的数据库用于了生产环境，就很难对他们进行修改，因此，在开发阶段设计好主键和外键就显得犹为重要。
对于主键而言，它是不可被重复的，而且尽量不包含特殊含义，毕竟主键的使用只是为了让数据库多一条高效的索引，而且在被外部引用的时候不会产生重复。同样重要的是主键最好不要和其他键一起组成复合主键，而应该单独用一列来表示。
正因为主键的特殊性，所以在大多数情况下我们都采用了自增字段来表示（但由于前台应用的特殊性，建议在表字段中增加一列有唯一约束的字段，用作前台显示用。比如，原来查看新闻可能是：news.php?newsId=123,这样别人很容易猜出下一条是124，前一条是122，平时这样使用是无所谓，但如果是使用在订单上，别人就很容易知道你的订单数量等，如果采用了GUID这样的值，虽然看起来复杂了一点，但永远不会被人猜出你的订单）
当然主键也可以使用这种GUID来进行设定，但确实是不太建议使用，我主要是指MYSQL，因为MYSQL默认没有默认生成这样键值的函数。而且使用定长字符串做主键，在被外部引用的时候，就显得太长了。
而外键就相对来说比主键约束要小的多，但也是有一定规范的。比如，用主键作外键，这是大多数人的用法。即使在MYSQL尚未支持外键的时候，大多数情况下。也都是通过这样的方式来进行关联。
在使用外键的时候，一般建议是不要超过4张表关联，超过4张，可能你在某些个表里就纯粹看到的是ID记录（类似于数据库的索引），这个时候麻烦的问题就来了。该如何维护这样一个全是ID记录的表呢？一旦这个表被人误操作了。那么。所有的数据都将失去关联了。（如果数据库支持外键功能，在删除这样的外键关联数据，我记得是会出错的。）
外键，除了使用主键外，还有就是那种具有唯一索引的列，仔细想想也确实这样，如果没有唯一，那么关联出来的数据怎么能够具有唯一性？
利用外键进行数据的更新删除，应该是最方便的了。这样也可以避免数据库里会存在冗余数据。
——END——
纯粹是在这里发发牢骚，真正的表设计不是这么简单的。还要根据实际的应用，但这些可以算是一些小小的经验。也许在真正的高手眼里这些都不值一提。但，千里马常有，而伯乐不常有啊。很多人都认为是理所当然的事情，不代表我们这些新手就明白。
记录下来，作为参考，也算是一个笔记
mysql主键（Primary key)，外键(references key)，unique key设置
2008-10-06 19:09
看一下下面的sql代码就可以了：
DROP TABLE IF EXISTS `Program_Release`;
CREATE TABLE `Program_Release` (
`id` mediumint(8) unsigned NOT NULL auto_increment,
`prog_id` mediumint(8) unsigned NOT NULL default '0',
`name` char(15) collate utf8_bin NOT NULL default '',
-- 主键
PRIMARY KEY (`id`),
-- unique键
UNIQUE KEY `name` (`name`),
-- 外键
KEY `FK_Program_Release_1` (`prog_id`),
CONSTRAINT `FK_Program_Release_1` FOREIGN KEY (`prog_id`) REFERENCES `Program` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin;
mysql只有InnoDB这个引擎支持外键。
在表建好之后设置外键的方法：
ALTER table IC_Release add foreign key(ic_id) references IC(id) on delete restrict on update restrict;
设置unique键的方法：
ALTER TABLE `Branch` ADD UNIQUE (`name`);