数据库主键外键设计原则sky-v博客园.docxVIP

数据库主键外键设计原则 - sky-v - 博客园 主键和外键是把多个表组织为一个有效的关系数据库 的粘合剂。主键和外键的设计对物理数据库的性能和可用性 都有着决定性的影响。 必须将数据库模式从理论上的逻辑设计转换为实际的物理 设计。而主键和外键的结构是这个设计过程的症结所在。一 旦将所设计的数据库用于了生产环境，就很难对这些键进行 修改，所以在开发阶段就设计好主键和外键就是非常必要和 值得的。 主键： 关系数据库依赖于主键 --- 它是数据库物理模式的基石。主键 在物理层面上只有两个用途： 惟一地标识一行。 作为一个可以被外键有效引用的对象。 基于以上这两个用途，下面给出了我在设计物理层面的主键 时所遵循的一些原则： 1. 主键应当是对用户没有意义的。 如果用户看到了 一个表示多对多关系的连接表中的数据，并抱怨它没有什么 用处，那就证明它的主键设计地很好。 2. 主键应该是单列的， 以便提高连接和筛选操作的 效率。 注：使用复合键的人通常有两个理由为自己开脱， 而这两个理由都是错误的。其一是主键应当具有实际意义， 然而，让主键具有意义只不过是给人为地破坏数据库提供了 方便。其二是利用这种方法可以在描述多对多关系的连接表 中使用两个外部键来作为主键， 我也反对这种做法， 理由是： 复合主键常常导致不良的外键，即当连接表成为另一个从表 的主表，而依据上面的第二种方法成为这个表主键的一部分， 然，这个表又有可能再成为其它从表的主表，其主键又有可 能成了其它从表主键的一部分，如此传递下去，越靠后的从 表，其主键将会包含越多的列了。 永远也不要更新主键。 实际上， 因为主键除了惟 一地标识一行之外，再没有其他的用途了，所以也就没有理 由去对它更新。如果主键需要更新，则说明主键应对用户无 意义的原则被违反了。 注：这项原则对于那些经常需要在数据转换或多数 据库合并时进行数据整理的数据并不适用。 主键不应包含动态变化的数据， 如时间戳、 创建 时间列、修改时间列等。 主键应当有计算机自动生成。 如果由人来对主键 的创建进行干预，就会使它带有除了惟一标识一行以外的意 义。一旦越过这个界限，就可能产生认为修改主键的动机， 这样，这种系统用来链接记录行、管理记录行的关键手段就 会落入不了解数据库设计的人的手中。 转载： /tianyamoon/archive/2008/04/02/1 134394.html 数据库外键的使用 外键的作用我认为主要有两个：一个是让数据库自己通过外 键来保证数据的完整性和一致性，一个就是能够增加 ER 图 的可读性。我觉得第二点的重要性甚至比第一点还高。 有些人认为外键的建立会给开发时操作数据库带来很大的 麻烦，因为数据库有时候会由于没有通过外键的检测而使得 开发人员删除 ,插入操作失败， 他们觉得这样很麻烦， 其实这 正式外键在强制你保证数据的完整性和一致性，这是好事儿。 应该说如果系统比较小，外键的作用可能不会很明显，如果 你的系统后台有几百个表的话，没有外键的数据库设计是我 无法想象的， 有一个基础数据的表 :商品， 其他表都保存商品 ID ，查询时需要连表来查询商品的名称，单据 1 的商品表 中有商品 ID 字段，单据 2 的商品表中也有商品 ID 字段，如 果不拉出外键的话， 当单据 1,2 都使用商品 ID 为 3 的商品后， 删除此商品后，再查看单据 1,2 的时候就会查不到商品的名 称 当表很少的时候，有人认为可以在程序实现的时候来通过写 脚本来保证数据的完整性和一致性，也就是在删除商品的操 作的时候去检测单据 1,2 中是否已经使用了商品 ID 为 3 的商 品，但是当你写完脚本之后系统有增加了一个单据 3 他也保存商品 ID 找个字段，如果不拉出外键，你还是会出 现查不到商品名称的情况， 你总不能每增加一个使用商品 ID 的字段的单据时就回去修改你检测商品是否被使用的脚本 吧 第二点就是增加 ER 图的可读性。这也同样是在后台数据库 表非常多的时候能够体现出来的，外键能够明确的两个表之 间的关系，例如一个单据的主表和单据的品的子表，如果两 个表没有拉出外键表明关系 ,且两个表的位置在 ER 图中很远， 对于一个对这个系统不是非常了解的人来说，让他去理出两 个表之间的关系是很麻烦的，如果你拉出外键就算两个表离 的很远，他也能随着外键找出他们之间的关系来， ER 图的 可读性对于一个刚刚接触大型系统的新手来说是极为重要 的。 当然，外键的个数也不是没有个尺度，因为外键拉的过多会 使 ER 图极为混乱 （ 到处都是线 ） ，所以应该掌握合适的尺度 才行，必要的外键必须要拉出来。如果实在不想因为外键过 多而造成 ER 图的混乱，可以对基础数据的删除用假删除的 办法，以避免在没有外键约束和检查的情况下