浅谈主外键约束

很久之前，就一直再看主外键的文章，然而从来没有写出一篇博客来对他们进行总结。迄今，尽管看了不少资料，令我汗颜的事是：有些文章所说的关于主外键的知识，我仍然不知所云，更别谈判断他们的对错。

之前，跟我的师傅沟通，勇哥建议我就地总结下。我也觉的，是我对这块知识进行总结的时候了。

下面就谈谈我对主外键的个人见解，同时，也会拿出我有想法的文章来和大家共同商讨。欢迎指正（嘻嘻）。

疑点一：要不要设置主键

开始学SQL Server的时候，就看到了有很多关于主键的设置，但是在我们的使用初期，并没有涉及到主外键约束的使用，只是单纯的使用SQL语句来维持数据的完整性。

在之后的学习中，渐渐的我们认识到了事务的重要性。原来自己做的数据库系统，设计之初没有充分考虑合理性、正确性以及系统的性能，致使系统在特定的条件下会出现处理错误、数据库中字段大量冗余、增删改查的时候由于设计的不合理会出现错误数据。

由于是按照让系统跑起来为原则设计出来数据库，越到后面越认识到它的局限性，不具有通用性。废话太多了，那么我们到底要不要设计主键呢？

我的认知是：一个系统不一定要设计主键，如果系统非常小，只需要几张表或者十几张表，在我们控制范围内，我们能够很好的保证系统的安全性，这样我们就可以完全不设置主键。

然而，一个数据库系统中不设置主键，则意味着每个表都将是独立的，我们需要花费额外的精力控制好数据的完整性；所以大多数表都需要创建，并且主键值必须唯一。

建立了主键约束，那么系统安全性就会大大的提高。那么是不是，所谓的所有的大项目的数据库设计都使用主外键约束呢？

不用想，建立主外键约束肯定是会影响系统性能的。在一个Web开发中，性能问题就非常重要了，如果系统安全性特别好，但是打开一个界面却需要有足够的耐性忍耐，那么我相信这个系统一定是悲剧的。所以并不一定所有大的项目都会使用主外键约束。

如此，建不建立主外键约束，我们就归结到数据的安全性与系统的性能的中和问题上来了。

那么安全性与性能，哪个因素影响的大，影响的程度到什么程度……纠结。

疑点二：怎样设置主键

下面看百科中主键定义：

主键（primary key）是被挑选出来，作表的行的唯一标识的候选关键字。一个表只有一个主键。主键可以由一个字段，也可以由多个字段组成，分别为单字段主键或多字段主键。

由上面的定义，我们可以知道，主键应该是有意义的，他应该是数据库表中某一具有代表性的字段。由三范式规范我们可以确定主键字段。

然而，百科中又约定如下原则：

1、主键应该是对用户没有意义的。如果用户看到了一个表示多对多关系的连接表中的数据，并抱怨它没有什么用处，那就证明它的主键设计地很好。

2、主键应该有计算机自动生成。如果由人来对主键的创建进行干预，就会使它带有除了唯一标识一行以外的意义。一旦越过这个界限，就可能产生认为修改主键的动机，这样，这种系统用来链接记录行、管理记录行的关键手段就会落入不了解数据库设计的人的手中。

原文链接：http://baike.baidu.com/view/68068.htm

针对原则1，我又知道，主键应该是没有意义。这一点让我迷惑了好一段时间，用牛腩的老师的话说就是“一群乱七八糟的东东”。如果我们设置主键，我们需要设置成为有意义的还是没有意义的呢？

网络中很多文章中也是出现同样问题，最开始说要设置有意义字段做主键，之后却在将主键设计原则中选用其他字段。

这里我们引入下一议题。

疑点三：数据库主键选取怎样的方式。

在网上找到资料，说通常情况下，可以有以下四中方式：

1、自动增长字段

2、手动增长字段

3、UniqueIdentifier

4、“Combine”类型

我们在上文牛腩新闻发布系统总结中

http://blog.csdn.net/liu765023051/article/details/7478466

提到自增长性字段会使得数据库中的主键经过增删改后变得乱七八糟（当然查数据的时候有办法使得其井然有序，这里不给出详解）。在这四种方式中，就会有相当好的办法解决上述问题。

具体参见此文：

http://www.cnblogs.com/longyi1234/archive/2010/03/24/1693738.html

文中作者讲的很好，也讲的很复杂，我不知道像他那样去去考虑好不好，我也想试试去自己实现之后再说好坏，试了几次没有成功，先把它挂起来吧。

这里讲到的四种方法，我只是用过第一种方法——自增长字段类型。后面两种类型打算遇到后在深入研究。