关于数据库主键的随笔

   随笔

   SnowFlake的使用体验：

   本次吸取上个项目经验，整个项目的数据库id都采用了 snowFlake，先说一下体验吧，snowFlake的确还是好用的，特别是在一些数据库操作上很方便，不用考虑很多，直接copy就完事了，出了问题修复上也比较方便：体现在如果缺少数据，你从主键上直接搜索就能很快定位缺失的数据，当然这种情况基本都没有出现。如果使用的是自增主键，要定位缺失或者不一致的数据，自增id并不能作为你参考的条件，你只能通过业务数据进行筛选定位。

   

    从业务主键过渡到id主键：

   上个项目我们的主键采用的是业务字段联合主键，这是因为之前的老项目全是oracle而且都是联合业务主键，这样做的好处也明显，数据的完整性不用后端去考虑，凡是不符合基本主外键关系的数据，不会写入到库里造成数据的污染。但是随着我们之后的项目逐渐过渡到以mysql数据库为主，业务主键的查询效率会下降，而且msyql也不推荐使用主外键关联，即数据完整性的控制，大部分都放到了后端程序。

  

   本次项目的教训

   这次项目的教训呢，是我一时没想明白，竟然用一个服务中某个实体的主键作为另一个服务的表的主键值进行保存，因为都是用snowFlake规范，不会出现主键冲突问题，而且这两个实体是强相关：都是某种用户的身份信息数据，只不过因为业务需要，才强行将注册、审核、激活进行了系统上的拆分，嘛，我当时认为不会出现问题。

   然而，你永远猜不透业务会提出什么需求，这种操作是要付出代价滴。现在业务突然提出了一个需求，导致我自认为强相关的实体，在A、B两个服务出现了不对应的情况，我为了在A中保存新数据，不得不将某些老数据做成轨迹表进行记录，否则会有主键冲突的情况。

   在这里记录一下，强相关就是不等于，两个系统你认为是一类甚至是相同的数据，会因为不同系统的拆分，不同系统的不同操作，导致最终不一致。

   正确的做法应该是，记录本系统自己的id，并记录另一个系统相关数据的id作为一个字段，这样对于需求的变化及兼容性就能提升很多了。