浏览 1571 次
|
锁定老帖子 主题：OECP中主键使用及生成策略探索
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 作者 | 正文 | |||||||||||||||
|
发表时间：2009-06-28
最后修改：2009-06-28
在OECP项目物理模型的架构设计的过程中，主键存储类型和生成方式的选择成了项目成员争论最激烈的部分。对于存储类型主要采用整形和字符型两种方式，有的成员倾向于统一所有的主键类型为字符型，整个系统采用统一的标准，方便系统的开发、整合。而最后我们还是决定根据实际情况，采用不同的主键类型。但是什么时候使用整形？什么时候采用字符型？字符型需要多少位？主键的生成应该采用什么方式？这都是需要我们仔细讨论的问题。
考虑这些问题无非从高效性和易用性上进行考虑。以下是几种主键生成策略的比较。
下表列出四种主键生成方式优缺点的比较：
从上表的对比中可以看出，问题的焦点还是在是采用高效的，但可控性、可移植性差的整形，还是采用能使用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的首选。 附自定义主键生成策略，完整版请查看：
参考资料：
HIBERNATE为什么不提倡用联合主键
声明：ITeye文章版权属于作者，受法律保护。没有作者书面许可不得转载。
推荐链接
|
|||||||||||||||
| 返回顶楼 | ||||||||||||||||
