关于数据库表应该采用逻辑主键还是业务主键的讨论
2005-03-24 16:05
555 查看
昨天令狐因为处理动网论坛的数据库时,发现它是用帖子号来作为主键,由于无意中对它作了一些修改,导致帖子的关联变得混乱了。于是我们讨论了一下数据库表中主键的选择问题。因为对动网论坛的程序不熟,所以我也不知道它是怎么设计实现的,今天令狐把JavaEye上的一个关于这个方面的话题拿来讨论就好办了。
我起初也觉得用一个无意义的逻辑主键是一个好办法,至少说用一个字段就可以唯确定一条记录,使用上会很方便,速度应该也会快些。但是看了JavaEye那个帖里的讨论,以及在QQ群里的讨论后,我发现不完全是这样的。
其实这是两种不同的设计思路,谈不上用逻辑主键一定比用业务主键好。
用业务主键是传统的C/S应用开发的思路,包括我现在用的SAP里,也大量使用业务主键。但如果用O/R Mapping,则可能用逻辑主键好一些。
因
为对于传统C/S应用来说,以典型的两层结构看,前端处理的是一个数据表示的工作,后端处理的是一个数据持久化的工作。业务逻辑分散在两端,特别是在后
端。因为需要在后端通过Stored
Procedure和View等来实现业务逻辑,应用直接与关系数据库打交道,所以数据的记录不但要求便于程序访问,对开发者来说,还要易读。也就是说需
要数据库的关系逻辑能够清晰地表达出业务逻辑来。主键采用业务主键是自然甚至是必须的。
而ORM应用恰恰相反。它需要一个最简单的
办法来标记一条唯一记录,但不需要有具体的意义,就像在OOP中,我们访问一个Object总是通过指针(或相似的引用),但我们并不需要知道这个指针具
体的值是0x89ABCDEF还是0xFEDCBA98。逻辑主键就相当于一个指针,当别的关联表引用到这条记录时,用一个外键字段记录了这个逻辑主键,
就相当于那个Object中有一个属性记录了一个指向这个Object的指针。这时如果用业务主键--特别是复合业务主键--就是存心给自己打麻烦了。最
糟糕的情况就是当需要修改这个业务主键的值的时候,会导致所有的关联发生混乱--在传统C/S应用中,我们是用Trigger来解决这个问题,但是在
ORM中不可能这样做,否则那还要ORM干什么?
当然,对于开发者来说,在ORM这样的情况下,用逻辑主键存在一个至关重要的问题
就在于数据的可读性将要变差。也就是说,除非通过OO的视角来看数据才是易于理解的。但如果直接进入后端看关系数据库,将变得困难。因此,基本上,逻辑主
键与ORM是相辅相成的,缺一不可,并且采用ORM的开发者要尽可能避免与后端的关系数据打交道,否则就会非常的痛苦。
正如令狐所作的总结:一个是从OO角度看,一个是直接深入数据库内部看。
我起初也觉得用一个无意义的逻辑主键是一个好办法,至少说用一个字段就可以唯确定一条记录,使用上会很方便,速度应该也会快些。但是看了JavaEye那个帖里的讨论,以及在QQ群里的讨论后,我发现不完全是这样的。
其实这是两种不同的设计思路,谈不上用逻辑主键一定比用业务主键好。
用业务主键是传统的C/S应用开发的思路,包括我现在用的SAP里,也大量使用业务主键。但如果用O/R Mapping,则可能用逻辑主键好一些。
因
为对于传统C/S应用来说,以典型的两层结构看,前端处理的是一个数据表示的工作,后端处理的是一个数据持久化的工作。业务逻辑分散在两端,特别是在后
端。因为需要在后端通过Stored
Procedure和View等来实现业务逻辑,应用直接与关系数据库打交道,所以数据的记录不但要求便于程序访问,对开发者来说,还要易读。也就是说需
要数据库的关系逻辑能够清晰地表达出业务逻辑来。主键采用业务主键是自然甚至是必须的。
而ORM应用恰恰相反。它需要一个最简单的
办法来标记一条唯一记录,但不需要有具体的意义,就像在OOP中,我们访问一个Object总是通过指针(或相似的引用),但我们并不需要知道这个指针具
体的值是0x89ABCDEF还是0xFEDCBA98。逻辑主键就相当于一个指针,当别的关联表引用到这条记录时,用一个外键字段记录了这个逻辑主键,
就相当于那个Object中有一个属性记录了一个指向这个Object的指针。这时如果用业务主键--特别是复合业务主键--就是存心给自己打麻烦了。最
糟糕的情况就是当需要修改这个业务主键的值的时候,会导致所有的关联发生混乱--在传统C/S应用中,我们是用Trigger来解决这个问题,但是在
ORM中不可能这样做,否则那还要ORM干什么?
当然,对于开发者来说,在ORM这样的情况下,用逻辑主键存在一个至关重要的问题
就在于数据的可读性将要变差。也就是说,除非通过OO的视角来看数据才是易于理解的。但如果直接进入后端看关系数据库,将变得困难。因此,基本上,逻辑主
键与ORM是相辅相成的,缺一不可,并且采用ORM的开发者要尽可能避免与后端的关系数据打交道,否则就会非常的痛苦。
正如令狐所作的总结:一个是从OO角度看,一个是直接深入数据库内部看。
相关文章推荐
- 主键的选择,应该是业务有意义还是业务无意义,应该是逻辑主键还是业务主键
- 关于每一个数据库表都应该有一个单一的字段作为主键的讨论
- 数据仓库 数据库 建模:关于业务主键和逻辑主键的取舍 - [s00n原作]
- 关于业务主键和逻辑主键
- 关于业务主键和逻辑主键
- 关于业务主键和逻辑主键
- 错过方知我不知:数据库设计中主键唯一且与业务逻辑无关的重要性
- 笔记:oracle关于使用代理主键还是逻辑主键的好?
- 关于业务主键和逻辑主键
- 逻辑主键还是业务主键?
- 关于sql中逻辑主键和业务主键的理解
- [原]关于数据库是否使用索引的讨论,我想说的
- Web应用程序应该采用函数式编程还是面向对象编程?
- 数据库设计逻辑主键
- 适合才是正确的 之 “关于业务逻辑加入存储过程”
- iOS开发那些事-关于性能优化–选择nib还是故事板的讨论
- 关于如何对待技术框架和业务框架的讨论
- 数据库分库分表(sharding)系列(三) 关于使用框架还是自主开发以及sharding实现层面的考量
- 性能优化--数据库优化--业务逻辑优化
- 数据库中存储日期的字段类型到底应该用varchar还是datetime ?