数据库中主键的选择和使用

数据库中主键的选择和使用
主键的选择：
1.有意义的键和无意义的键：
有意义的键：例如身份证号。

键值是唯一的，而由人来指定是不可靠的，有可能会出现重复，虽然数据库可以检测出来，但是在数据进入系统之前不会被发现。

所以有意义的键是不可靠的。

无意义的键：本质是数据库构造的并不打算供人使用的一个随即数。

对应小系统或稳定的情况，应优先考虑。

2.简单键和组合键：
组合键：在一个表和另一个表上下文相关时更易于使用。

比如：订单号加上顺序号来作为订单的键值。

简单键：一致性好。

如果都使用简单键，在对键的操作中可以使用相同的代码。

而组合键需要特殊处理。

3.表唯一键和数据库唯一键：
表唯一键：在一张表中是唯一的。

数据库唯一键：对任意一个表的任意一行都是唯一的。

4.取得新键：
(1)数据库自动生成：
优点：简单
缺点：难以确定新生成的键值。

当插入主从表数据时比较麻烦。

(2)数据库计数器：
缺点：没有统一的标准，也不是所有数据库系统都支持。

(3)GUID：
优点：可以确定是唯一的键，所以是安全的。

缺点：生成的结果串比较大，会影响性能，尤其对索引。

(4)键表：
构造：一般有两列：名字，下一个键值，如果使用数据库唯一键，那么表中就只有一行数据。

如果使用表唯一键，对每个表都有一行数据于之对应，每向数据库中增加一个表就要对应的在键表中增加一行。

使用：取出数据行，获得数字，进行增加操作，得到新数字，把新数字写回到数据行中。

在更新键表时，也可以通过增加一个适当的值来一次获取多个值，既减少了数据库调用，也减少了对键表的争夺。

应当把对键表的操作放在一个独立的事务中，如果使用表唯一键，那么在新增的同时将锁住键表中对应的行，这意味着锁住了所有对表的插入，如果使用数据库唯一键，则意味着锁住了对所有表的插入。

个人感觉：自增值用起来简单，但是业务逻辑复杂后感觉就比较麻烦。

组合键，特别是主键字段多的时候操作起来很麻烦，业务逻辑部分要很熟悉才行，因为很容易产生主键冲突。

键表，感觉用起来最清楚，但是键生成算法要自己来写。

说明：主要参考Martin Fowler的《企业应用架构模式》(Patterns of Enterprise Application Architecture)的第十二章“对象－关系结构模式”的12.1.1节精简总结而来。

BTW：这本PEAA实在是一本难得的好书，Martin Fowler的组织，讲述能力非常好，得Jolt大奖真是当之无愧啊。