数据库设计 逻辑主键

在数据库设计中我们经常会存在是否为表建立逻辑主键（代理主键）的问题。

使用逻辑主键的好处：

 

1.业务系统中需要关联时使用逻辑ID进行关联－－而不是有业务ID做关联－－使业务系统具有最大的灵活性，及业务ID也是可以修改的，如果使用业务ID做主键，则该条记录就不能被修改。但是这种情况时有发生。
例如：现在客户所有产品编号要升级在原来基础上加上分公司编号。如果系统采用逻辑ID关联则可以方便的修改产品编号。否则的话

2.优化了表的设计，避免使用联合主键。

 

3.进行多表查询时可以通过关联逻辑ID来提升性能.

 

4.逻辑ID一般采用整形，业务ID通常使用字符类型。整形相对与字符类型无论在建立索引还是外键关联查询效率要高的多。

 

5.使用Hibernate等ORM工具时，获得一些性能提升。（这也是Hibernate所推荐的）

 

6.至于业务ID的唯一性约束可以通过唯一性索引来约束

下面引用论坛上的一些片段：

  

 

 

引用

在对象建模时也有逻辑主键，只是隐含了而已。一个逻辑主键的意思就是对象实例的唯一性，简单地说，人的身份证号码是业务主键，而具体的人则隐含着一个逻辑主键，也就是说不管出现什么样的情况，你还是你(当然不要跟我讲克隆， )。
   在做建模的时候我们当然不会考虑这个问题，因为它和实例有关系，和对象（指的是建模层的对象，不是类的实例）是没有关系的，所以在做建模时是不会考虑的。这也就是我们为什么叫它逻辑主键的意思（表明它在现实领域是看不到，但是是逻辑存在的）。
    再将上面的例子反应到计算机领域，如果拿业务主键身份证作为人的唯一判断，那么就出现了一个问题，所有引用改身份证的地方，如果出现了身份证的改动（客观存在，谁的身份证都升了位），那么将带来很大的麻烦（这种麻烦在现实领域好处理，并且有足够的时间进行处理，但是在计算机领域就不简单了）。
    我的建议：对于业务数据，是需要采用逻辑主键的，对于基础数据，基于多方面考虑，是可以采用业务主键的。

 

引用

   逻辑主键的作用只是关联引用，没有任何别的作用，而在表内的唯一性是通过业务唯一性（建立唯一约束）来保证的。
    我是提倡业务数据采用逻辑主键，基础数据可以根据实际情况采用业务主键的（这里所谓的业务主键并不是业务数据，而是所称的比如国家，货币，城市代码等等之类）。
    我从来不是那种走极端的，因为如果一味全部用逻辑主键，在处理复杂业务的时候，就真的很麻烦了，因为一张业务表往往关联更多的基础表。但是，在业务表里也用所谓的业务主键，那就更差了（基础的东西往往很少改，即算要改，都是有比较长的时间量，并且都是为大家所共知的；而业务的东西，是每一个做软件的最薄弱的，并且是最有可能受到客户影响的，也会是最会引起问题的）。

 

引用

   只要是由用户维护的数据，信息系统就不能假设它不会变。很简单，用户维护的时候会出错。出错了就要改。逻辑主键应该是指没有业务含义，没有业务用途，因此不需要用户维护，甚至不需要给用户看的。因此它也就绝对不会变。这才能真正满足主键“唯一，不变”的要求。

 

引用

   业务主键一般不会是单独的一个字段，那么，在这种主从关系中，是很痛苦的
尤其是我们做的ERP系统，经常会有多层的级联 H-MD-MD这样的结构，如果使用业务主键，简直是不可想象的
所以，基本上都是UUID作为主键

最后，如何在运行效率，开发效率以及维护上找个平衡点是关键！！！