为什么需要一个ID

不知道从什么时候开始，但凡设计数据库表结构的时候，几乎毫无例外的，大家想都不用想，首先创建一个字段，名称叫ID，类型是 LONG，顺序增长，作为表的主键 ……

显然这已经成为一种公认的模式了，但这确实是一个好的模式吗？为什么一定要用一个毫无意义的ID来作为记录的主键呢？

理由之一：性能。貌似用整数作为主键的话，在以主键为条件进行关联查询的时候，进行的是整数的比较要比用字符串比较更快一些？貌似很有道理，但实际上细想一下缺是站不住脚的，首先比较并非整个查找过程的全部运算；其次，字符串的比较操作，也不需要一个字符一个字符的比较，长度不同首先就基本排除了一大部分不符合的情况；再其次，如果字符串字段被用作主键的话，那么如果我给它建立主键的时候，显然是要考虑到查询的快速匹配运算的，数据库厂商不可能连这么简单的常识都不考虑到，假设索引树是基于字符串的HASH值建立的，那么在字符串索引中查找和在整数索引中查找，简直就是完全一样的计算量。

理由之二：可以改名，一般对象都有一个类似名称的字段，一般这个字段也是业务主键，因此如果用ID作为关联外键的话，那么父记录的名称变了，不影响子记录的ID引用，因此从父子记录关系依然保持着，且从子记录查询父对象的名称时，自然就查到了更改后的名称。然而这一点同样不成立，现在恐怕已经找不到不支持级联更新的数据库产品了，既然数据库本身支持级联更新，那么关联关系直接建立在名称上同样通过级联更新可以继续维持父子关系并自动将子记录中的父记录名称更新。

理由之三：hibernate 等 orm 东东需要一个主键，而且如果是复合主键的话，一般都比较麻烦。这个理解太牵强，首先就算数据库就是仅仅为hibernate使用而建立的，那么用业务主键作为库表的主键任然是没有什么问题，复合主键的问题，完全可以通过将复合主键通过字符串拼接组装为一个单一主键来解决。

总而言之，ID作为主键实在是毫无理由可言，但是不用ID作为主键的理由，倒是充分得很：

第一：不必要的关联，通常在记录呈现中，子记录的关联字段要显示父记录的名称，用ID做主键，必然要进行一次关联查询才能得到。

第二：无法进行延迟关联，很对应用场景中，对关联关系的管理并不是那么严厉的，往往可以运行先输入子记录中相关字段的值，即使这时候父记录还没有创建，此后一旦父记录创建了，那么关联关系自然就建立起来了，而用ID进行关联，显然就无法实现这中自动的延期关联，在父记录创建后，必须要在子记录中进行一种普查将关联关系在补充上去。