主键和外键是把多个表组织为一个有效的关系数据库的粘合剂。主键和外键的规划对物理数据库的性能和可用性都有着决定性的影响。

　　必须将数据库模式从理论上的逻辑规划转换为实际的物理规划。而主键和外键的结构是这个规划过程的症结所在。一旦将所规划的数据库用于了出产环境，就很难对这些键进行修改，所以在开发阶段就规划好主键和外键即是非常必要和值得的。

　　主键：

　　关系数据库依赖于主键---它是数据库物理模式的柱石。主键在物理层面上只要两个用途：

　　1. 惟一地标识一行。

　　2. 作为一个能够被外键有效引用的对象。

　　基于以上这两个用途，下面给出了我在规划物理层面的主键时所遵循的一些原则：

　　1. 主键应当是对用户没有含义的。若是用户看到了一个表示多对多关系的衔接表中的数据，并诉苦它没有什么用处，那就证明它的主键规划地很好。

　　2. 主键应该是单列的，以便提高衔接和筛选操作的功率。

　　注：使用复合键的人一般有两个理由为自己开脱，而这两个理由都是错误的。其一是主键应当具有实际含义，可是，让主键具有含义只不过是给人为地破坏数据库提供了便利。其二是使用这种方法能够在描述多对多关系的衔接表中使用两个外部键来作为主键，我也反对这种做法，理由是：复合主键常常导致不良的外键，即当衔接表变成另一个从表的主表，而依据上面的第二种方法变成这个表主键的一部分，然，这个表又有能够再变成其它从表的主表，其主键又有能够成了其它从表主键的一部分，如此传递下去，越靠后的从表，其主键将会包含越多的列了。

　　3. 永远也不要更新主键。实际上，因为主键除了惟一地标识一行之外，再没有其他的用途了，所以也就没有理由去对它更新。若是主键需要更新，则阐明主键应对用户无含义的原则被违反了。

　　注：这项原则对于那些经常需要在数据转换或多数据库合并时进行数据整理的数据并不适用。

　　4. 主键不应包含动态变化的数据，如时间戳、创建时间列、修改时间列等。

　　5. 主键应当有计算机主动生成。若是由人来对主键的创建进行干预，就会使它带有除了惟一标识一行以外的含义。一旦跳过这个界限，就能够产生认为修改主键的动机，这样，这种系统用来链接记载行、管理记载行的关键手段就会落入不了解数据库规划的人的手中。

　　外键是数据库一级的一个完整性束缚，即是数据库基础理论书中所说的“参照完整性”的数据库完成方式。

　　外键属性当然是能够去掉的，若是你不想再用这种束缚，对编程当然不会有什么影响，但相应的录入数据的时候就不对录入的数据进行“参照完整性”查看了。  

　　例如有两个表

　　A(a,b) :a为主键，b为外键（来自于B.b)

　　B(b,c,d) :b为主键   

　　若是我把字段b的外键属性去掉，对编程没什么影响。

　　如上面，A中的b要么为空，要么是在B的b中存在的值，有外键的时候，数据库会主动帮你查看A的b是否在B的b中存在。

　　1、外建表达的是参照完整性：这是数据固有的，与程序无关。因此，应该交给DBMS来做。

　　2、使用外建，简单直观，能够直接在数据模型中表现，无论是规划、保护等回有很大的优点，特别是对于剖析现有的数据库的优点时非常明显的--前不久我剖析了一个企业现有的数据库，里面的参照完整性束缚有的是外键描述，有的是用触发器完成，感觉很明显。当然，文档里能够有，可是也能够不全，可是外键就非常明显和直观。

　　3、既然咱们能够用触发器或程序完成的这个工作（指参照完整性束缚），DBMS已经提供了手段，为什么咱们要自己去做？并且咱们做的应该说没有RDBMS做得好。实际上，早期的RDBMS并没有外键，现在都有了，我认为数据库厂商添加这个功能是有道理的。从这个角度来说，外键更便利。

　　4、关于便利，根据我带项目的状况来看，程序员确实有反映，主要是在调试时输入数据费事：若是数据能够违反参照完整性，那么即是说参照完整性本身就不对名誉业务冲突，此时也不应该用触发期货程序完成；否则，阐明数据是错误的，根本就不应该进入数据库！并且，这也应该是测试系统的一个内容：阻碍非法数据。实际上，前台程序应该对这种提交失败做出处置。数据是企业的而非程序的，储程序要尽量与数据分离，反之亦然。

　　最后说一下,建键几个原则:

　　1、 为关联字段创建外键。

　　2、 一切的键都必须唯一。

　　3、避免使用复合键。

　　4、外键总是关联唯一的键字段。

　　想要了解更多详情欢迎来电咨询18678812288，或登陆网址www.jnydkj.com。联系人：王经理。地址：济南市舜耕路泉城公园东门园内向北50米