谈谈企业信息系统数据库设计是使用id主键还是uuid逻辑主键或业务主键

  企业信息系统泛指企业ERP、OA、MES等企业管理软件，这些系统都有共性：业务层面较技术层面更加复杂，体现在数据库上就是业务表往往字段很多，超过4-5个字段的业务主键随处可见。从10余年的企业信息化系统建设及当下分布式应用出发，谈谈在企业信息化系统中应该如何设计数据表主键。

一、数据表主键的演变

1、C/S阶段， 业务主键

  最初在一家国内最大民营饮料企业上班，当初大部分系统都是自建的，基于C/S架构，PowerBuilder作为客户端直连sybase数据库。当时，基本上所有表都是业务主键，比如：
  1）员工表，工号就是主键；
  2）客户表，客户编号就是主键；
  3）客户费用表，客户号+年+月+费用项是主键；
  为了产生工号、客户编号等流水号，还建了一个序列号表，每次取编号都从序列号表获取并返写。

优点：
企业信息系统业务上有个特点，经常会隔段时间将生产机（PRD）库的数据导到测试库（TST），供业务部门测试用。该阶段，数据迁移非常方便，怎么导都行。
缺点：
当时阶段，真没发现有什么大的缺点，因为PowerBuilder datawindow 很强大，数据更新、删除不要想开发人员写sql（前提datawindow 构建的时候要指定好哪些是主键、更新哪些字段），调用PFC即可。

2、B/S阶段，开始使用id主键

  随着业务发展，有些业务经销商（客户）要自己做，如：报站（下订单）、报损、费用兑现查询等，为此上线了客户门户系统，B/S架构，jsp+tomcat应用服务器+sybase数据库。
  当时，数据库所有操作，都需要java开发人员写sql，问题来了，更新一张业务主键复杂的表，sql中要写很多where条件，工作量大，而且容易出错。为此，部分表开始使用id主键，于是就可以根据ID操作单个对象了，效率、性能显著提升。
优点：
sql操作方便，效率较高。
缺点：
数据迁移问题来了，PRD数据导入导TST库，不能直接使用，需要做处理。

3、分库阶段，开始使用uuid逻辑主键

随着业务发展，sybase数据库锁机制的缺陷被逐渐放大，业务操作相互等待现象愈加明显，于是使用了postgresql数据库替代了sybase数据库，不同业务使用不同postgresql数据库，各业务基础数据放到公用数据库，做可忽略延迟同步。个别业务又进行了客户分库，内部客户订单走内部客户库，外部客户走外部客户库。
一开始继续使用ID主键，内部客户订单和外部客户订单需要合并时发现，id冲突，于是引入uuid逻辑主键，所有id关联全部使用uuid，业务库内部sql操作仍然可以使用id。
优点：
sql操作方便，数据迁移方便。
缺点：
sql效率略微降低，增大存储空间，uuid产生算法还待考验。

二、当下企业信息化系统数据表主键设计建议

1、所有表统一使用id物理主键；

2、部分表使用uuid当逻辑主键（id需要被其它表依赖，使用uuid关联）；

3、部分表使用业务主键唯一索引，将最早的业务主键改成业务唯一性索引；