如题，请说明理由，表关联也是用字符串吗？
This topic created in 1352 days ago, the information mentioned may be changed or developed.
 |
ktqFDx9m2Bvfq3y4Mar 1, 2023 via iPhone
1
整型自增。
放心，系统下线了用户都不会有那么多。 |
 |
zoharSoulMar 1, 2023
2
不是, 基本都是整形
|
 |
shyangsMar 1, 2023
3
別和百度貼吧踩同一個坑。
哪天產品拍腦袋, 說百度帳號(用戶名)要可以讓使用者自由地更名, 你要學貼吧在 username 裡加各種符號避免重複? |
|
4
承上，所以區分 id 和 name,
id 用整型自增，系統決定，使用者不可更改 id ，只能改 name 。 |
3 |
justfinduMar 1, 2023
5
自增, 如果你要避免被扫, 那就 uuid 呗
|
 |
op351Mar 1, 2023
6
因为用主键的整型自增列会暴露其他用户，所以不会用主键的整型自增列
而是自增列之外设计一个单独的用户 ID 列 使用三方库根据日期之类的生成不会重复的字符串 |
 |
xiaoliu926Mar 1, 2023
7
@op351 我这边的项目都是雪花算法生成主键 id 的,安全的很
|
 |
LeegoYihMar 1, 2023
8
bigint
实际接口都会鉴权，不存在通过 ID 被暴力遍历的情况 |
|
op351Mar 1, 2023
9
|
 |
NoKeyMar 1, 2023
10
有时候对外叫 userID ，他实际不是 id ，用户 id ，要区分业务层面的 id ，和数据层面的 id ，你讲的是哪一个？😆
|
 |
chendyMar 1, 2023
12
自增，怕被爆破就在接口层加一层编码规则处理，变成火星文（比如加上固定前后缀然后取字节然后翻转然后 base64 啥的）
|
 |
superedlimitedMar 1, 2023
13
为什么 mongodb 自动生成的_id 是一串字符串呢
|
 |
abelyaoMar 1, 2023
14
已经习惯了能用 uuid 就用 uuid 了，或者 nanoid - https://github.com/ai/nanoid
|
 |
god7dMar 1, 2023 via iPhone
15
guid
|
 |
16
用自增 ID 的这些建议，不考虑横向 sharding 问题吗？雪花生成全局唯一 ID 就行了
|
 |
fiypigMar 1, 2023
17
我第一家公司就用字符串的 用户账号， 现在的用自增，也有用 UUID ，我还没遇到过。。
|
 |
manasheepMar 1, 2023
18
无脑 GUID （ UUID ）就可以了，MongoDB 的话用它自己的 ObjectID 也行
|
 |
dk7952638Mar 1, 2023
19
id 是给系统用的编码，no 是给人用的编码
id 最好是自增，如果是分布式可以用雪花算法，自增可以提高数据库性能，还能实现游标分页 no 一般都是有意义的，比如快递单号 |
 |
tool2dMar 1, 2023
20
爆破很好处理的，你 api 加密一下就可以了。或者加个一次性访问权限，nonce 那种参数。
只要索引建的好，字符串查找速度也不慢的。 |
|
21
@superedlimited MongoDB 的 ObjectId 也是根据 Timestamp 和 MachineID 自增的 bigint ，只不过它是 12 字节 96 位的整数，用字符串方便展示
|
|
superedlimitedMar 1, 2023
22
@LeegoYih #21 谢谢，我查了一下文档，原来它是 16 进制的数字。我是直接用的 mongodb 的免费 cloud 数据库，还没仔细看文档。
|
 |
vitoliuMar 1, 2023
23
BIGINT 毋庸置疑，具体生成规则，看用户 ID 包含不包含对外业务含义，包含对外业务含义生成规则不能包含趋势递增。
|
 |
xuanbgMar 1, 2023
24
我选择雪花 ID 。用字符串是什么鬼？ UUID ？
|
|
ktqFDx9m2Bvfq3y4Mar 1, 2023 via iPhone
25
@melkor
有太多系统到废弃那天用户到不了那么多。自增没什么不好。 |
|
ktqFDx9m2Bvfq3y4Mar 1, 2023
26
|
 |
acvrockMar 1, 2023
27
BIGINT +1,UID 大概率是其他业务表的索引,越短越好,最好趋势递增
但是不能简单的自增,否则用户规模会被外部猜测出来,或者被扫描爆破 |
 |
pkoukkMar 1, 2023
28
内部系统用数据库自增
对外系统用雪花，UUID 太长了，占存储太多了，而且最主要的坑是如果拿 uuid 当主键，插入性能太差了 虽然用户不太可能用户注册有太高并发，但是如果你需要用备份恢复一个库或者增加一个从库的时候就要疯 |
 |
allinoneokMar 1, 2023
30
如果你的 ID 需要写入 cookie 并加密就选择随机生成 id
|
 |
RICKEYGONGMar 1, 2023
32
Guid userId = new Guid();
|
 |
leerayaMar 1, 2023
33
bigint 够够的
|
 |
b821025551bMar 1, 2023
34
@melkor 雪花成本应该是最高的，在大部分引擎下，无序主键会导致查询性能降低，以及空间浪费
|
 |
youismeMar 1, 2023
35
@b821025551b 雪花算法是有序的
|
 |
afstyleMar 1, 2023
36
@b821025551b 建议你好好看看雪花 id 算法
|
 |
AshoreMar 1, 2023 via Android
37
你离职了以后都不会有那么多的用户的。放心吧
|
 |
cnbattleMar 1, 2023
38
推荐雪花 id ， 需要注意的数 如果前端是 js ，json str 转 json 对象 数字 大于 17 位时会丢失精度 得前端或后端特殊处理下
|
 |
karlokuMar 1, 2023
39
字符串的索引性能不行, 作为主键还是用整型好
不管是 mongodb 的 ObjectId 还是 UUID 本质上也只是被表示为 16 进制的定长 bits, 在数据库里可以用 binary(12) 或者 binary(16) 存取. mysql8 里有直接用于转换字符串的函数 `UUID_TO_BIN()` / `BIN_TO_UUID()` 和生成用的 `UUID()` . postgres 则是直接支持 uuid 类型的字段, 支持在 sql 里用字符串进行写入和查询. 不需要满足可排序性的时候可以用 uuidv4. 需要满足可排序性的时候可以用 mongodb 的 ObjectId 和 128 位的 ulid. |
 |
litchinnMar 1, 2023
40
准确来说，雪花算法那个叫单调递增。
参与的有一个项目，最开始是自增，但是后面有个客户有个需求，他部署了两套系统，A 、B ，但是每天要将 B 系统的数据全部同步到 A ，然而这些数据里有关联 id ，于是只能改成雪花算法生成的 id ，bigint 也用过字符串类型的 id ，但是因为没办法单调递增且自己 debug 很不方便所以个人并不喜欢 目前使用雪花算法 id ，数据库 bigint 并且设置自增 |
 |
BeforeTooLateMar 1, 2023
41
整数自增问题用户容易被爬虫遍历吧，比如你是 id1 ，我是 2 ，只要一个个试过去就行了
|
 |
liuidetmksMar 1, 2023
42
@BeforeTooLate 不成熟的想法，自增一个比较大的素数就行了。uint64 溢出也不要紧，正好相当于取模了
|
 |
realpgMar 1, 2023
43
unsigned uint64 自增
多库分布系统就他自己自增 然后复合唯一索引带 node_id ，合并一起做 userid |
|
realpgMar 1, 2023
44
|
 |
DanfiMar 1, 2023 via Android
45
数据库查询用 bigint ，对外输出 hashid
|
 |
46
职业生涯遇到过好几次数据库迁移，得到的教训就是数据库尽量不要用自增 id ，不然迁移表数据简直是灾难
|
 |
polo3584Mar 1, 2023
47
区分 uid 和 uname 就行
|
 |
zzzzz001Mar 1, 2023
48
@BeforeTooLate 平时写接口注意点，带上当前登录人的标记去数据库查，只查当前登录人的信息，不就避免被刷了吗。这样的思路很多
|
 |
f9EHtxE2UtX3fG3Mar 1, 2023 via Android
49
用户 id 直接数据库自增？都不分表的吗？
|
 |
lovelylainMar 1, 2023
50
整型自增，对外加密，就像微信的 openid 一样，虽然不清楚具体实现，但应该是可以解密得到整型自增 uid 的
|
|
lovelylainMar 1, 2023
51
@ccagml 分库分表也可以自增呀，例如百库十表，取 uid 低 10 位标识在哪个表，右移 10 位得到在具体表中的自增 id
|
 |
hsuyeungMar 1, 2023 via iPhone
52
bigint ，然后对外 hashid
|
 |
WaldenHorizonMar 1, 2023
53
用了很多年 uuid ，完全代替了自增数字，并且封装在所有使用过的框架中
除了一点点性能问题，好像没什么缺陷了吧 |
 |
zhaogazMar 1, 2023
54
看需求吧。。
首先看你这个用户 id 定义成什么，还有就是个人习惯，公司习惯，代码项目习惯啥的。 有的是 us-xxxxx ；有的是 uuid ；有的是自增数；有的是长整数，这和 是不是字符串都没关系。。。 你想问的是数据库的实现，和 用户 id 设计没啥关系。。数据库层面，一般用 固定 char 就行。。你数据库存成数字有什么优势么？你想一想 然后再解释下自增 id：自增 id 相当于把 id 生成的事情扔到 db 了。看你们个人习惯和项目习惯，不是不可以。如果数据关联的逻辑也扔给 db ，这么做都没啥问题。 其实都挺新手的问题，大概能猜到 op 工作环境。 |
 |
twofoxMar 1, 2023
55
无脑雪花主键啊。。UUID 不建议，太长和分散，不适合索引
|
 |
ZhiyuanLinMar 2, 2023
57
为了防爬虫丢掉自增 ID 有点小题大做了，用户量不大的话完全可以给进出 API 接口的自增 ID 跑个对称加密，防爬+性能兼得。这年头 AES 加解密的开销比 DB lookup 一个字串 ID 小多了。
|
 |
wind8866Mar 2, 2023
58
用字符串作为 ID 的要注意一下数值特别大的情况，接口返回 JSON 格式时要用程序转成字符串，别超过最大安全数。吃过这方面的亏
|
|
melkorMar 2, 2023 via iPhone
59
@b821025551b 主键都是聚簇索引，都排好序的，为啥会影响读性能？
|
Select Language