针对hibernate应用的表设计,最好设计一个非逻辑主键id吗?大家怎么做的
2016-05-02 20:08
411 查看
hibernate的应用,一定需要主键的。
很多书上或网页都推荐针对hibernate的表设计时,设计一个独立的主键id,跟业务逻辑无关系的。但是我在实际应用中,发现有些业务涉及主外时,使用跟业务逻辑有关的主键很方便。
问题补充:谢谢各位,这几天忙去了。
确实主键和业务脱离,能增加灵活性。
现在,我总结下,看对不对
用独立主键:
优点:
1. 能和业务逻辑解偶,如后期的业务变化,主键不会变化(这个比较重要,一般程序里getId()被用到的地方很多)
2. 知道id的情况,访问数据比较快,直接,且方便做成通用处理(各表主键id同名)
缺点:
1. 有时访问数据不大方便,应用上经常关心业务数据,在这种情况下,如果要得到记录,需要先得到id,再利用id,得到记录
2. 业务应用上,业务主键字段用于查询比较多,通常会建立索引,这样主键id也有索引,索引多了,增加了空间,影响更新速度
3. 如要对数据做主外键(业务上的数据约束),由于表主键只有一个,这时建立不了约束
-----
对数据完整性约束要求较高的情况下(如数据比较总重要,不能出错的情况下),用业务逻辑字段做主键。其它情况用独立主键。
另外,用独立主键时,在hibernate中,可以建立维护主外键关系(这样应该可以吧,相当在应用层约束数据完整性)
很多书上或网页都推荐针对hibernate的表设计时,设计一个独立的主键id,跟业务逻辑无关系的。但是我在实际应用中,发现有些业务涉及主外时,使用跟业务逻辑有关的主键很方便。
问题补充:谢谢各位,这几天忙去了。
确实主键和业务脱离,能增加灵活性。
现在,我总结下,看对不对
用独立主键:
优点:
1. 能和业务逻辑解偶,如后期的业务变化,主键不会变化(这个比较重要,一般程序里getId()被用到的地方很多)
2. 知道id的情况,访问数据比较快,直接,且方便做成通用处理(各表主键id同名)
缺点:
1. 有时访问数据不大方便,应用上经常关心业务数据,在这种情况下,如果要得到记录,需要先得到id,再利用id,得到记录
2. 业务应用上,业务主键字段用于查询比较多,通常会建立索引,这样主键id也有索引,索引多了,增加了空间,影响更新速度
3. 如要对数据做主外键(业务上的数据约束),由于表主键只有一个,这时建立不了约束
-----
对数据完整性约束要求较高的情况下(如数据比较总重要,不能出错的情况下),用业务逻辑字段做主键。其它情况用独立主键。
另外,用独立主键时,在hibernate中,可以建立维护主外键关系(这样应该可以吧,相当在应用层约束数据完整性)
相关文章推荐
- Android:studio 导入工程报错finished with non-zero exit value 1解决方案
- 从假洋河酒事件看 电商监督制度缺失
- online_judge_1208
- 解决UDP服务器并发困难
- 欧几里得算法求最大公约数的递归和非递归实现
- java的静态代理
- List--LinkedList(浅识)二
- Volley相关知识
- Python爬虫折腾纪录
- 待整理内容
- nyoj_42 一笔画问题
- 3. Longest Substring Without Repeating Characters
- 动态规划——最少硬币问题
- hdu 5677 ztr loves substring 多重背包
- Android Studio 文件名颜色代表含义
- elk搭建完整搭建【篇1】
- Golang实现红黑树
- iOS中黄色文件夹和蓝色文件夹的区别
- 文章标题
- 默认参数与占位符参数