OECP中主键使用及生成策略探索

在 OECP项目 物理模型的架构设计的过程中，主键存储类型和生成方式的选择成了项目成员争论最激烈的部分。对于存储类型主要采用整形和字符型两种方式，有的成员倾向于统一所有的主键类型为字符型，整个系统采用统一的标准，方便系统的开发、整合。而最后我们还是决定根据实际情况，采用不同的主键类型。但是什么时候使用整形？什么时候采用字符型？字符型需要多少位？主键的生成应该采用什么方式？这都是需要我们仔细讨论的问题。

考虑这些问题无非从高效性和易用性上进行考虑。以下是几种主键生成策略的比较。

下表列出四种主键生成方式优缺点的比较：

主键生成策略	优点	缺点
自动增长字段	1.  使用简单	1.  不同数据库获取当前值方式不同； 2.  难以应用在多个数据库间进行数据迁移的情况。 3. 不能集群化
手动增长型字段	1. 可以获得最新键值 2.  可以确保数据合并过程中不会出现键值冲突	1. 通常情况下需要建立一张单独的表存储当前主键键值； 2. 增加一次数据库访问来获取当前主键键值； 3.  考虑并发冲突等，增加系统的复杂程度。 4. 不能集群化
使用 GUID	1.  直接生成 GUID ，获得最新键值以填充主键，使用方便； 2. 可以确保数据合并过程中不会出现键值冲突； 3.   避免了前两种方式获取当前键值所增加的开销。	1. 占用较多存储空间； 2. 索引耗时； 3.  在多表链接查询时效率不如 int 型
使用 “COMB” 类型	1.  保留 GUID 的已有优点； 2.  利用时间信息与 GUID 组合起来，增加有序性以提高索引效率。	1. 需要设计 COMB 的生成算法； 2.  和 GUID 一样占用较多存储空间； 3.  在多表链接查询时效率不如 int 型，但优于 GUID 。

从上表的对比中可以看出，问题的焦点还是在是采用高效的，但可控性、可移植性差的整形，还是采用能使用 GUID 这样可控性和移植性高，但是效率低，存储大的字符型主键，真有点鱼和熊掌不能兼得的味道。（ COMB 需要设计生成算法，增加程序的复杂度，如果算法不当，会产生意想不到的结果， GUID 也可以通过优化索引的方式提升性能，暂不使用 COMB ）

从数据库的角度来看，整形虽然查询的效率最高，但是数据的合并、移植存在着很大的问题，同时高并发的情况下，各种整形的生成方式都面临这问题，而且不利于集群化处理。而采用 GUID 生成方式的字符型，能很好解决集成和并发性的问题，但占用空间大，查询效率低可能成为系统运行后将出现的问题。

从程序开发的角度上看，整形生成方式的生成主键非常方便，但是主键的获取，需要整个事务结束，才能从数据库中取到，同时在多关联表保存的时候，需要先保存主表，将产生的主键传给字表，从而也可以造成性能的缺失，并且无法直接获取主键，会增加程序开发处理的复杂性。而字符型的主键，需要程序人员自定义主键生成规则，需要认为的干预主键的生成，但是主键可以在插入数据库之前就能拿到，方便程序的处理。

从系统数据的角度来看，业务数据可能存在大量的并发，采用 GUID 的方式是非常方便的，在数据级别很大的情况下，可以方便的进行集群化处理。档案型数据并发量小，但是被引用的多，数据合并和集成的情况也很多，完全使用整形是不合适的，完全采用 GUID ，又会引起性能的缺失，需要更加折中的方案，既保证使用可控性较强的能唯一标识的字符串，同时又要尽量降低字符串占得字节数。而对于系统辅助数据，根据实际情况灵活使用，不做硬性统一，在数据量较小的情况下，尽量采用整形。

结合项目中使用的 JPA+Hibernate 的特点，在主键的使用和生成策略上，初步确定采用一下的方案：

1、          对于大业务量的数据，采用 UUID 的主键生成策略。

2、          对于没有太多关联查询的数据，采用 UUID 的主键生成策略。

3、          对于使用数字型的主键生成，采用 JPA 的 table 生成策略，而不使用依赖数据库的生成策略。

4、          对于档案型的数据（主数据），采用字符型的主键，长度定为 10 ，采用自定义的主键生成方式。（后面附我的简单实现）

5、          尽量避免使用联合主键的方式，统一采用无意义的逻辑主键。

Robbin 的意见：

在 Hibernate 来说，一个 PO 状态的判定完全依赖于主键属性的值，甚至很多 PO 的隐形的级联操作，例如关联对象的是否级联增加 / 更新这些判定也完全依赖于主键属性的值，所以主键属性值的维护对于 Hibernate 能否正确的运行，正确的持久化数据至关重要。

如果当你使用无意义的逻辑主键的时候，主键的维护完全是由 Hibernate 自动进行的，你无须关注主键的维护，自然就避免了很多问题的产生；而如果你选择自己手工维护主键 ( 联合主键就必须手工维护 ) ，所有的这些维护主键的重任都必须由你来负责，你必须小心翼翼的编程，避免造成无法正确持久化，对于一个不是非常精通 Hibernate 的人来说，这通常比较难达到，更何况在分层架构中， Web 层程序员仅仅操作 DAO 接口层，他更加不了解 PO 状态维护的个中微妙之处，极易犯错误那也是在所难免。

所以采用无意义的逻辑主键一定 Hibernate 的首选。

 

附自定义主键生成策略，完整版请查看：

http://ww.po-soft.com/blog/yongtree/159.html

 

 

该《OECP中主键使用及生成策略探索》出自于百洋软件研究实验室

参考资料：

Guid 和 Int 作为系统编号的取舍

HIBERNATE为什么不提倡用联合主键

以 GUID 當做主鍵(PK)對於效率的影響

数据库主键设计之思考

再议《反驳吕震宇的“小议数据库主键选取策略（原创）” 》