数据库数据量大了以后,用自增ID主键做关联不好吗?

MrGu 发布于 2015/09/12 10:13
阅读 2K+
收藏 0
公司的项目,用的MYSQL,所有表都是用自增ID作为主键,另外有的表还会有一个number编号字段,编号是根据一定的规则生成的,规则基本上是根据当前时间生成一个字符串再拼上一个序号, 表与表之间的关联是通过主键来关联,比如有店铺和商品表,店铺表有ID和number,商品表也有ID和number,商品表里有个"店铺ID"的字段,用来和店铺表做关联,来确定商品属于哪个店铺。现在项目已经做了一大半,项目负责人突然说要改为用number字段来进行关联,说是便于今后的数据迁移和维护。在我看来,用自增ID确实不利于数据的迁移,但是用number做关联后,不仅项目的大量代码要重写,似乎也无法解决数据迁移的问题,如果要解决数据迁移问题,应该改变ID的生成规则才行吧,比如用guid。我跟项目负责人提出异议,但是他坚持要这样改,说我考虑得不够远,说大型的系统都不会用id主键去做关联,想请教下各位大神,真的是这样吗?
加载中
2
m
magiclogy

用number做关联,是不是应该确保number就是主键,number做主键,命名成id,不是非常合适么?

1
tinshen
tinshen

按照你的说法number和uuid用法都一样的。

如果一开始没有这样的结构考虑,真心是自找的。


0
四維海滨
四維海滨
等有那个规模,重写也不算事。
0
alexgaoyh
alexgaoyh

个人觉得都可以:

使用number做表关联的话,不管是后期数据迁移,还是集群环境,都不会受影响,但是主键id的用处就有些淡化了。

如果修改主键id的生成规则的话,就需要考虑比较多,避免后期的大部分问题。


0
ihuotui
ihuotui
用uuid最好
0
M
MrGu

引用来自“magiclogy”的评论

用number做关联,是不是应该确保number就是主键,number做主键,命名成id,不是非常合适么?

其实我就是这个想法,相当于更改ID的生成规则,不用自增ID,这样基本就不用修改原有代码了
0
PynixWang
PynixWang

看存储引擎,inno的话最好不要用uuid做主键。。。

0
zigzagroad
zigzagroad
一直用uuid,除了占用存储空间,没看出哪里不好;主键都是有索引的,不管是不是数字类型。
0
魔力猫
魔力猫

我觉得你的项目负责人才是作死。你这里说的nubmer字段不是说主键本身是数字类型而是把原来的那个编号改成主键用。

如果仅仅从数据库角度,这么修改结构无所谓。实际上自增ID也不怎么妨碍所谓的迁移。真要迁移,无数代码结构要改,也不差自增ID一个。而且其他数据库也不是没有自增ID功能。

但是项目本身过半,这样大改的成本它考虑了么,引入的BUG风险是多大考虑了么。完全就是随便拍脑袋就把项目起码延期出一大截(如果各种修改测试严格,多30%时间都不夸张)。

0
M
MrGu

引用来自“魔力猫”的评论

我觉得你的项目负责人才是作死。你这里说的nubmer字段不是说主键本身是数字类型而是把原来的那个编号改成主键用。

如果仅仅从数据库角度,这么修改结构无所谓。实际上自增ID也不怎么妨碍所谓的迁移。真要迁移,无数代码结构要改,也不差自增ID一个。而且其他数据库也不是没有自增ID功能。

但是项目本身过半,这样大改的成本它考虑了么,引入的BUG风险是多大考虑了么。完全就是随便拍脑袋就把项目起码延期出一大截(如果各种修改测试严格,多30%时间都不夸张)。

改了以后,主键还是原来的ID,不过number也是唯一的,我也感觉这么改不但需要花很多时间,而且也不能带来什么好处,关键并不是所有的表都有number,所以搞到后面有的地方用id做关联,有的地方用number做关联,感觉相当混乱。
魔力猫
魔力猫
不用主键用另外的进行关联,真是奇葩了。而且有的地方用有的地方不用,完全把完整性破坏了。最后还是个杯具。
返回顶部
顶部