一、问题
发现很多表设计(包括我们的大部分主要数据库表设计),都会有一个自定义的字符串作为业务处理字段,自增主键ID作用并不是很大,请问这样设计有没有必要性和合理性?
抛弃这一个字段完全使用自增主键ID会不会有什么缺陷?
二、解答
解答1:
自增主键要慎用。特别是数据库表自带的那种,在数据迁移和传输过程中都会带来很多问题。
很多业务主键都要设计编码规则和范围,以便于表述。比如一个物料号,你可以定义其编号范围是RAW001~RAW99,前缀RAW表示原材料,后三为是序列号。这样的编码规则有利于记录和口头传播。
有些年轻的开发者由于从前台技术入手,非常不注意数据模型的设计,喜欢用自增主键或者UUID等,这是一种很坏的习惯。一则如上所说不利于表述;二则体现其思维狭窄性,不懂从数据结构和信息处理出发的思考习惯。这种情况下,建议多读一些数据库理论知识,以拓宽自己的编程思维,改善思考定势。
解答2:
首先你要明白数据库第二范式的规定,一张表一定要有一个主键,所以在此情况下,最方便的做法就是采用自增字段作为主键,因为一张表的自然的具有唯一性的属性字段通常是无法确定的。
其次,我不太明白你所说的“一个自定义的字符串作为业务处理字段”是什么意思?如果是订单号之类的字段,那如果你能确保这个字段对于这张表是具有唯一性的,当然可以不用自增字段作为主键,而直接用这个业务字段作为主键(但实际项目中,你会体会到这个想法挺幼稚的)。而如果你只是想用一个UUID去代替自增字段作为主键,那么大可不必,因为这个UUID如果没有承载业务意义(也就把它作为订单号之类的),它会比自增ID占用更多的存储空间,而且在生成UUID时,还占用了应用服务器的CPU等资源。
最后,“完全使用自增主键ID进行应用开发和业务处理,会有什么问题吗?”当然没有问题啊,设计自增字段的目的就是为了让你把它作为主键的,因为基本上在所有的数据库引擎中,一张表只能有一个自增字段。至于说把自增字段用于业务处理,这个是取决于需求,如果需求方能接受自增字段作为订单号之类的具有业务意义的字段,当然没有问题,但如果不接受,你还是要增加字段去处理。
再提一句,就算是分布式数据库,自增ID其实方案还是挺多的,完全不用担心。
解答3:
没什么问题,只是担心数据量。而且自增的索引在很多时候提高检索效率
自增主键应该作为表的数据记录唯一标识,不应该有业务意义;
即便主键id变化,也不用担心id变化造成业务出现问题,
主键id变化情况:数据迁移,类型变更等
解答4:
没什么问题,只是担心数据量。而且自增的索引在很多时候提高检索效率
解答5:
自增主键应该作为表的数据记录唯一标识,不应该有业务意义;
即便主键id变化,也不用担心id变化造成业务出现问题,
主键id变化情况:数据迁移,类型变更等
解答6:
分表的时候会有问题。业务表最好不要用自增主键,一般采用雪花算法来做。