错过方知我不知：数据库设计中主键唯一且与业务逻辑无关的重要性

很早以前听朋友说过，阿里的数据库设计中要求主键必须与业务无关。当时也就是耳朵听了一下，也默认，不过没做细致的思考。这段时间维护公司的一个程序需要修改业务功能的时候，在诟病原有程序的设计是有多么傻的时候，突然又想起了那句话，有很深的体会，于是我写下了这篇文章，也是我来博客园写下的第一篇文章。

我面对的场景如下：

之前的数据库设计每条记录是没有主键的，只有业务逻辑上的主键，比如产品大类Id，产品小类Id，产品使用方Id（打比方，请勿深究，只想表达这三个字段是这条记录的联合主键）。业务逻辑都是在存储过程中进行实现。每次的接口调用都会传递这三个业务逻辑上的组合主键，然后存储过程中都会有类似 产品大类Id=xxx and 产品小类Id=xxx and 产品使用方Id=xxx这样的sql语句。

现在我所要做的修改是：产品需要有更新升级，也就是说现在逻辑上的主键需要有 产品大类Id，产品小类Id，产品使用方Id 版本号 这四个字段。

我感觉新加入进来的这个“版本号”这个有主键逻辑意义的字段对于之前的所有业务逻辑代码来说就是灾难，牵一发而动全身：界面接口调用传参要修改，后台逻辑代码要修改，数据库存储过程要修改。如果说代码都是自己写的改动起来可能没什么，关键是那些古老的代码已无主多年，又无甚注释。还能看见一个存储过程中一大段一大段重复复制的sql语句。

然而我也就只能是吐槽一下了，虽不愉快，该做的还是要去做。静下心来回想一下，这个不是设计上的缺陷吗？

如果最开始设计的时候就使用了一个与业务逻辑无关的自增的唯一主键，界面传参根后台代码逻辑都无需做大的变动，至于说存储过程中的逻辑，也可以修改的很少。而且写sql的时候只有一个条件不是比写三个and语句省事的多吗。

感觉问题还是出在写代码前没有怎么思考过。觉得业务是怎样的就怎样写，勤勤恳恳地做好功能，大不了自己多写几句sql，还能跟人夸吹嘘一下“你看我又写了2000行sql”，哈哈，想起来了这个

引用：我找到的阿里的开发规范的文章http://blog.csdn.net/wnjok/article/details/78264537点击打开链接