业务主键 Vs. 逻辑主键，到底用哪一个？

gclizh · 发表于 2008-9-28 16:24

原帖由 evan_shen 于 2008-9-28 15:33 发表
我认为这个问题其实并没有绝对的答案，如果是单一部署的我认为逻辑主键要好，但是分布式部署呢，看看以下的例子：
假如有这样一个系统，杭州、宁波、温州和浙江省等各部署一个一套库，各自一个库，互相不联网，其中有一个表的数据在各自的系统中作增加，在年底的时候都要导到省里的系统，这时候如果采用逻辑主键的话，杭州就有一条Id为100的记录，宁波或其他地方同样会有一条Id为100的记录，两条记录根本就没有关系，导入到省里以后两条记录就冲突了，id100不知道代表那条记录，这时候就要用业务主键在保证全省唯一，大家认为是逻辑还是业务好呢

目前我们遇到这样的问题是这样处理的 xx||to_char(seq.nextval,'0000000000000000000')
比如北京的数据就是 ‘01’||...

我们一般都是使用sequence 做主键，业务上需要保证唯一的加上uk

业务数据做主建的问题我觉得下面的问题
1.如果数据需要修改会带来很多麻烦，比如那身份证做人的主键，但是身份证号码输入错了。
2.如果系统结构复杂的时候，引用层次比较多，可能出现主键列很多的情况，使得性能受到影响
3.如果业务上说这个列不是唯一的了，那就麻烦了

不过业务主键也有好处，比如查询的时候因为业务数据放到了引用表中，可能可以减少关联，
这一点，我们在使用逻辑主键的时候有的时候是通过冗余数据解决的

angus_shi · 发表于 2008-9-28 16:42

个人倾向于用业务主键：
1、逻辑主键看起来解决了数据的唯一性问题，但是恰恰对实际数据的不唯一性提供了后门，经常要加一个业务的唯一索引，画蛇添足。
2、对数据的迁移带来不必要的麻烦，有时候为了这个主键而不得不在建sequence的时候进行人为的分段，而在进行测试数据生成或者是数据迁移的时候，更是一个大麻烦。
3、只在对数据进行编辑和删除的时候才起作用，对于应用最多的查询来说根本就没有一点作用，而如果只是为了用一个字段来定位记录的话，完全可以用rowid代替
4、对数据空间的占用，一个用处很少的字段，如果数据量大的话，占用的空间，也不会少吧
同意前面
开发人员喜欢用逻辑主键，管理人员喜欢用业务主键的说法
层面不同，关注点也不一样

[ 本帖最后由 angus_shi 于 2008-9-28 16:43 编辑 ]

petitlen · 发表于 2010-1-23 01:40

于甲方，数据就是命根子，使用业务主键，数据的完整性，关联性清楚明了，上层业务系统怎么改数据都不会乱，但可能工作量大些（相对）。

对于乙方，总是希望工作量越小越好，所以一般选择逻辑主键，也不管你企业的数据存储空间如何，不管你数据今后好不好升级，不管有没有垃圾数据，只要保证在我的维护期内能搞定即可。

但请注意，在数据大批量修改时，使用业务主键工作量会大些，但约束使你不会出错；使用逻辑主键，貌似工作量小，但必须很小心，万一出错了，可能数据就会大面积错乱，也许无法弥补。

我的观点：http://www.cnblogs.com/petitlen/articles/1654534.html

lzfzl · 发表于 2010-1-23 07:03

逻辑主键对性能没有好处
在高并发的OLTP上，如果同时三实施业务主键唯一约束和逻辑主键的主键约束，DML的成本增加了，并发性能降低了
在OLAP或DSS上，数据如果是按逻辑主键的顺序加载的，逻辑主键的索引集群因子最小，业务主键索引的集群因子偏高，但业务上的查询更多是对业务主键索引的索引范围扫描或全索引扫描，性能就降低了