主键的选择

青旅半醒 2021-09-17 21:10 510阅读 0赞

主键的选择：  
1.有意义的键和无意义的键：  
有意义的键：例如身份证号。键值是唯一的，而由人来指定是不可靠的，有可能会出现重复，虽然数据库可以检测出来，但是在数据进入系统之前不会被发现。所以有意义的键是不可靠的。  
无意义的键：本质是数据库构造的并不打算供人使用的一个随即数。对应小系统或稳定的情况，应优先考虑。  
2.简单键和组合键：  
组合键：在一个表和另一个表上下文相关时更易于使用。比如：订单号加上顺序号来作为订单的键值。  
简单键：一致性好。如果都使用简单键，在对键的操作中可以使用相同的代码。而组合键需要特殊处理。  
3.表唯一键和数据库唯一键：  
表唯一键：在一张表中是唯一的。  
数据库唯一键：对任意一个表的任意一行都是唯一的。  
4.取得新键：  
(1)数据库自动生成：  
优点：简单  
缺点：难以确定新生成的键值。当插入主从表数据时比较麻烦。  
(2)数据库计数器：  
缺点：没有统一的标准，也不是所有数据库系统都支持。  
(3)GUID：  
优点：可以确定是唯一的键，所以是安全的。  
缺点：生成的结果串比较大，会影响性能，尤其对索引。  
(4)键表：  
构造：一般有两列：名字，下一个键值，如果使用数据库唯一键，那么表中就只有一行数据。如果使用表唯一键，对每个表都有一行数据于之对应，每向数据库中增加一个表就要对应的在键表中增加一行。  
使用：取出数据行，获得数字，进行增加操作，得到新数字，把新数字写回到数据行中。在更新键表时，也可以通过增加一个适当的值来一次获取多个值，既减少了数据库调用，也减少了对键表的争夺。应当把对键表的操作放在一个独立的事务中，如果使用表唯一键，那么在新增的同时将锁住键表中对应的行，这意味着锁住了所有对表的插入，如果使用数据库唯一键，则意味着锁住了对所有表的插入。  
  
个人感觉：自增值用起来简单，但是业务逻辑复杂后感觉就比较麻烦。组合键，特别是主键字段多的时候操作起来很麻烦，业务逻辑部分要很熟悉才行，因为很容易 产生主键冲突。键表，感觉用起来最清楚，但是键生成算法要自己来写。  
  
说明：主要参考Martin Fowler的《企业应用架构模式》(Patterns of Enterprise Application Architecture)的第十二章“对象－关系结构模式”的12.1.1节精简总结而来。  
BTW：这本PEAA实在是一本难得的好书，Martin Fowler的组织，讲述能力非常好，得Jolt大奖真是当之无愧啊。  
  
  
转载说明：这篇文章分析的非常好，其实对我们的应用上来说，可以自定义一个生成键值的类或者函数，用来取得新的键值，类似guid的方法，或者直接由guid获取处理生成，一个连贯的新的键值，但是产生的较长的键值怎么处理？调用的时候怎么才能更快？所以这是一个需要考虑的问题！我想应该分开考虑，有的表采用类似guid，有的采用数字，如分类表！