昨天令狐因为处理动网论坛的数据库时，发现它是用帖子号来作为主键，由于无意中对它作了一些修改，导致帖子的关联变得混乱了。于是我们讨论了一下数据库表中主键的选择问题。因为对动网论坛的程序不熟，所以我也不知道它是怎么设计实现的，今天令狐把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角度看，一个是直接深入数据库内部看。
