1
wy315700 2016-06-25 19:13:45 +08:00
short_uuid
|
2
sudoz 2016-06-25 20:30:22 +08:00 via Android
万一最大了呢?
|
3
colatin 2016-06-25 20:58:37 +08:00
按我说,应该用 varchar
|
4
ins 2016-06-25 21:03:03 +08:00
他们是想很长远之后的 需求和省事所以都选 long 型
|
5
Livid MOD 如果应用支持第三方登录,或者只使用第三方登录,那么第三方的 User ID 有可能是 64 位的。虽然自己的应用不一定能增长到超过 32 位,但是第三方很可能是 64 位的。
|
6
iyaozhen 2016-06-25 21:28:36 +08:00 via Android
还是有一定道理的,确实能超过 21 亿,改代码都快改哭了。
还有 L 大说的兼容第三方 |
7
infun 2016-06-25 21:32:25 +08:00
我司 32 位升级 64 位专门立了个项目
|
8
hp3325 2016-06-25 21:42:45 +08:00 via Android
浪费?那是你没遇到溢出!
改代码,导数据的时候就不会觉得浪费了。 |
9
qgy18 2016-06-25 21:43:42 +08:00 via iPhone
百度 passport 当年就遇到 id 长度不够的问题,改了好久。
|
10
chaegumi 2016-06-25 21:45:56 +08:00
int 还要是无符号的,不然对接百度登录就不够
|
11
redtea 2016-06-25 21:48:21 +08:00
突然想到前公司一业务表的从表主键 id 就是 int ,如果业务繁荣的话,估计就要溢出了。
|
12
wdlth 2016-06-25 21:51:44 +08:00
不用自增而用算法生成主键的话,无符号 bigint 也不算多长。
|
13
Ouyangan 2016-06-25 21:53:04 +08:00 1
业务中使用 uuid , 第三方可以另建一张表维护
|
14
moult 2016-06-25 22:01:17 +08:00
听我的,用 char ,存 36 进制的,初期长度不够的时候前面补 0 。。。。。
|
15
ayaseangle 2016-06-25 22:02:01 +08:00
垃圾数据很快就超过了。。
|
16
bobuick 2016-06-25 22:03:46 +08:00
uuid 会影响 index ,各位说用 uuid 的记得指明场景, 不然误导人家了要
|
17
liashui 2016-06-25 22:09:19 +08:00
前期 int ,后期修改为 long 的工作量多大呢?
|
18
moult 2016-06-25 22:15:25 +08:00
@liashui 强类型语言的话,伤筋动骨很厉害,一个地方该类型,关联一堆的地方。
PHP 的话,直接查出来是 string 格式的,而且 ID 这种东西一般不会拿来加减乘除,无痛不痒。 |
21
hantsy 2016-06-25 22:26:28 +08:00
内部 UUID , 外部 Base58
|
23
gefranks 2016-06-25 22:31:44 +08:00 via iPhone
我司一个产品也是快溢出了 出补丁出的疯掉
|
24
ETiV 2016-06-25 22:46:14 +08:00 via iPhone
LoL 还是 DotA (印象中是拳头),之前停机维护,就是因为数据库主键类型选的不够多…
|
26
zkd8907 2016-06-25 22:54:05 +08:00
腾讯旗下的 QQ 和微信都曾经因为 32 位的问题而专门立项,全公司大改。这个成本不管对于多大的公司来说,都是非常巨大的。
|
27
mickeyandkaka 2016-06-26 00:29:05 +08:00
生成全局唯一的 id ,这样不同业务用同一个 id 生成器后,各个子业务方便合并。
|
28
Lucups 2016-06-26 00:36:30 +08:00
当你有那么大量级的用户笑都来不及,还怕改?
PS :不要过度设计。 |
31
programgou 2016-06-26 01:14:40 +08:00
|
32
viator42 2016-06-26 01:37:07 +08:00 via Android
Android 的列表 id 值必须定义为 long
公司后台把只有两种值的字段都定义成了布尔类型,简直是不要命 |
33
BB9z 2016-06-26 01:54:52 +08:00
用户 ID 一般是够了,但用户产生的数据可能要多两个甚至三个数量级,业务发展好的两三年可能就需要考虑了。
|
34
realpg 2016-06-26 02:04:00 +08:00
说明这个公司用的不是 PHP ……
|
35
msg7086 2016-06-26 06:44:43 +08:00
如果你的系统不打算长期用、大规模用的话,当然可以用 int 。
人家公司是打算做大做强的,当然就用 long 了咯。 你看看现在的 IPv4 不就是 int 么, IP 分配都搞成什么鸟样了…… |
36
beginor 2016-06-26 08:09:53 +08:00 via Android
id 用时间字符串,精确到毫秒后面的三位数,类似这样 201606260812123654 便于排序和查看
|
37
zealinux 2016-06-26 10:10:12 +08:00
图省事就用 int ,
(以后有你哭的,不要说要改的时候,你跑了哦。) 图未来就用 long |
38
hggg 2016-06-26 11:46:27 +08:00 via iPhone
没遇到过 int 不够(T⌓T),哭晕在厕所
|
39
quericy 2016-06-26 12:02:02 +08:00
我们就是用的 int ,感觉到不了要用 long 的时候。。。。
三方登录单独建表维护 |
40
tianice 2016-06-26 12:25:07 +08:00
很多业务表都会有 userId ,如果后期再改,修改量巨大。
很多公司为了业绩好看,会自己做一些数据,你懂得。。。 |
41
fuxkcsdn 2016-06-26 14:07:57 +08:00
PHP 果然是世界上最好的语言
这算啥事啊,你改下数据库表结构就得啦,关我代码鸟事 |
42
starqoq 2016-06-26 15:54:47 +08:00
我记得 Dota2 的服务器曾经就为对战记录的主键溢出问题下线修补过一次。
官方公告还说 “我们 2038 年会再见面的”。 |
43
Cloudee 2016-06-26 16:54:04 +08:00 via iPhone
反过来想,为啥每条记录多 4 个字节算浪费...等业务量大到需要计较每条记录 4 字节的空间,也要笑开花了吧
|
44
daydaysay 2016-06-26 18:02:13 +08:00
50 亿行记录,用 long ,也就 4 * 21 亿字节 , 8G 硬盘。 内存不知道,多 8G ?
其实既然有人提出出了用 long , 我觉得也不麻烦,是好事。 |
45
daydaysay 2016-06-26 18:03:17 +08:00
是多用 4 * 21 亿字节。 前一条说得不完整
|
46
qiukun 2016-06-26 18:57:38 +08:00 via Android
typedef 一下?
|
47
doushiyinweini 2016-06-27 09:18:00 +08:00
随便,对于拥有几十亿用户的公司对于改个数据类型都是小儿科。
|
48
techme 2016-06-27 11:27:39 +08:00
嗯,数据库有一些“浪费”是必要的,之前设计一个任务报告的表最多限制能写 2000 字,结果有人写了 8000 多字,页面保存不上去把我们骂的那个惨啊
|
49
JQ 2016-06-27 14:43:20 +08:00
长度不够的情况,遇到过 2 次。
|
50
symbo 2016-06-29 20:02:09 +08:00
@doushiyinweini 成本挺高的。修改,测试,上线,耗费的时间和人力不少。
|
51
arist 2017-05-16 17:53:08 +08:00
前前任使用了一个诡异的算法在自增主键上生成 id, 前任后来把这段代码废弃,使用默认的自增 id, 不到一周,现任发现游戏新用户注册不了, 检查后发现了 int 溢出, 持续了几个小时,留下一大波差评,惨痛的教训。
|