这是一个创建于 891 天前的主题，其中的信息可能已经有所发展或是发生改变。
数据表里 id （单库，自增数字）和 name(长度 10 个以内的英文字符串)是唯一的。
后端不返回 id ，接口都让前端用 name 字符串获取数据，
不是为了防采集。就是觉得很少见到用可读的字符串作为查询的条件，想问一下这样做会有什么问题吗？
第 1 条附言 2023-07-12 14:04:42 +08:00
总和来看，目前的结论是可以的。
只要 name 有 unique 约束
自增 id 主要是为了提高一点点的性能。内部关系可以用 id 关联。
但返回的数据和查询条件都只能通过 name ，要问为啥的话，可能只是因为 1.我这个案例比较特殊 name 确实不会重复而且是可读的 2.如果用可读的字符串来查，不知道怎么说，可能更自然吧，个人喜好。3.既然可以用 name 查，就没必要用 id 查了，防止出现查询条件不统一的情况。4.如果我把 api 公开，我希望精简易懂。没有多余的字段，如果 name 可以替代 id ，那么 id 是多余的。
只要 name 有 unique 约束
自增 id 主要是为了提高一点点的性能。内部关系可以用 id 关联。
但返回的数据和查询条件都只能通过 name ，要问为啥的话，可能只是因为 1.我这个案例比较特殊 name 确实不会重复而且是可读的 2.如果用可读的字符串来查，不知道怎么说，可能更自然吧，个人喜好。3.既然可以用 name 查，就没必要用 id 查了，防止出现查询条件不统一的情况。4.如果我把 api 公开，我希望精简易懂。没有多余的字段，如果 name 可以替代 id ，那么 id 是多余的。
 | 1 webfamer 2023-07-11 23:43:11 +08:00 id 唯一，名字会重复 |
 | 3 pengtdyd 2023-07-11 23:46:51 +08:00 可以 |
 | 4 mmnsghgn 2023-07-11 23:55:50 +08:00  1 可以，另外可以试试 https://hashids.org/ 把 id 加密一下 |
 | 6 mineralsalt 2023-07-12 00:04:20 +08:00 4 不可以, 一般默认 name 是变动的, 是一种不确定的值, id 是不变的, 用 id 查更可靠, 其次 id 查询速度现对于字符串的 name 更快, 要养成良好的编程习惯, 一般前后端传值都是用 id, 又没特殊需求, 就遵循默认不好么, 干嘛特立独行, 当然业务需求非用 name 当然也没问题 |
 | 7 b1t 2023-07-12 00:19:42 +08:00 能用，但这种方式不可取，反驳的槽点很多 |
 | 8 witcat OP @mineralsalt 谢谢，我想延伸再问一下，假设 name 大多数时候创建了就不会变，但如果变了，会有什么后果吗？ 我目前能想到的就是用户用浏览器把这个页面收藏了，后面再访问数据就不见了。 因为我也好奇，微博、推特这些网站也是用 用户自定义的 id 定位一个用户，但都不能修改。还有什么其他原因吗？ |
 | 10 shakukansp 2023-07-12 00:29:12 +08:00 前端框架比如 vue react 渲染表格都需要给每一个表格项绑定一个唯一的 key ，用来复用元素或者检测变更 你不给前端就要自己弄一套自增的 id 来标记，为啥不直接给呢？ |
| 11 witcat OP @shakukansp name 可以作为 key 啊 |
 | 12 tangtj 2023-07-12 00:41:04 +08:00 1 两个用户 a 和 b name 在短时间内 name 都改变了, b 用户改成 a 用户之前的用户名 . b 是否会查到 a 的数据 |
| 14 shakukansp 2023-07-12 00:42:49 +08:00 @witcat 看了下，name 不重复的话可以 |
| 15 witcat OP @shakukansp #14 |
 | 16 moonrailgun 2023-07-12 00:51:50 +08:00 1 第一，id 可以作为后续操作的唯一标识，比如你要点击到某一条记录肯定不能是第几条或者某个 name 第二，id 可以作为前端缓存的唯一标识，当然如果不做缓存当我没说 第三，如果这个列表是动态更新的，id 可以优化前端渲染性能(在 mvvm 框架) 第四，代码洁癖，一条记录一定要有一个唯一 key ，不然纯粹靠数组会不放心，当然这个洁癖可以没有 |
 | 17 chendy 2023-07-12 08:24:27 +08:00 有 id 就老老实实用 id ，id 用到系统下线公司关门都不会重复 name 今天不重复说不定以后会重复，或者日后有其他业务规则上来需要 name + 其他某些字段才能确定是哪一条数据就要坐牢了 |
 | 18 Dragonphy 2023-07-12 08:43:44 +08:00 name 可能会有需求变动要求可更改，不如用一个 nanoid 字段，但这和 id 其实没啥区别 |
 | 19 darkengine 2023-07-12 08:53:01 +08:00 把自增 id 暴露出来其实有一定风险的，例如可以通过 id 的值判断你们业务大概到了什么量级。 |
 | 20 MEIerer 2023-07-12 09:02:52 +08:00 via Android ...... |
 | 21 Laysan 2023-07-12 09:14:24 +08:00 把业务 ID 和数据库自增 ID 区分开 |
 | 22 LeegoYih 2023-07-12 09:24:04 +08:00 “怕被爬数据而不返回 id”，我只能说是后端开发能力有问题。 即便是自增的也不会有这种问题，资源权限数据权限基本上能覆盖 99%。 |
 | 23 Tyaqing 2023-07-12 09:37:48 +08:00 雪花 id,id 中间层 hash 转换都能解决这个问题 |
 | 24 dode 2023-07-12 09:41:33 +08:00 前端篡改了 id 还要后台校验 |
 | 25 EthanLiu1993 2023-07-12 09:44:12 +08:00 看需求吧，都唯一的用哪个都行 |
 | 26 InDom 2023-07-12 09:44:40 +08:00 1 不要用业务相关字段与代码强绑定。 只要这个 name 是用户产生的，就一定不要在代码中作为关联使用。 你可以不使用 id ，但必须再额外生成一个与用户无关，原则上用户也永远看不到的唯一字段。 |
 | 27 DoubleKing 2023-07-12 09:49:06 +08:00 不要用自增的 id ，也不要用 name 这个字段，即使你的 name 不会重复，这会在后期维护中造成不必要的误解 |
 | 28 me1onsoda 2023-07-12 09:50:35 +08:00 没搞懂。这么做跟直接用 id 有什么区别吗？ id 天然唯一，name 你得分配一个 unique 索引，为什么要做这么多余的事情？ |
 | 29 gogo789 2023-07-12 09:52:58 +08:00 这个没啥不可以的，前端查询用的就是一个唯一标识，name 加一个唯一索引，保证不会重复。但是 name 这种二级索引需要回表，查询效率相对 id 的话会差一些。 |
 | 30 unco020511 2023-07-12 10:02:27 +08:00 只要是保证唯一,当然是可以的 |
 | 31 lisongeee 2023-07-12 10:04:05 +08:00 如果使用 name 作为查询依据，比如之前的微博，你在微博发布动态去艾特别人，等到别人改名字之后你再点击动态里的艾特就显示查无此人，之后另一个用户改成你艾特的名字，你再点击动态里的艾特就跑到后者用户的主页了 |
 | 32 hundredFlowers 2023-07-12 10:05:39 +08:00 可以，但没必要 |
 | 33 hu1e 2023-07-12 10:07:47 +08:00 不可以，后续你 name 不要编辑更新了吗？ |
 | 34 ktqFDx9m2Bvfq3y4 2023-07-12 10:12:56 +08:00 @darkengine HashId 了解一下，而且这个还可以用来校验。比如把 Id+随机数一起生成 HashId ，根据 Id 加载数据，随机数跟相应的记录一起保存，那么就可以实现某种程度的验证，比如分享某条数据给别人。 |
 | 35 monologue520 2023-07-12 10:59:15 +08:00 按照一般约定, 列表需要提供 ID, 能减少很多问题 |
 | 36 suyuyu 2023-07-12 11:00:48 +08:00 后续要删改根据什么字段呢？ |
 | 37 Huelse 2023-07-12 11:03:41 +08:00 下个需求就是根据 id 单独查询，总不会根据 name 来查吧？ |
 | 38 yxzblue 2023-07-12 11:05:24 +08:00 可以，你是后端，想怎么返回都可以的， |
| 39 darkengine 2023-07-12 11:09:41 +08:00 @Chad0000 混淆 ID 有很多方案，例如每条记录带个 UUID ，前后端交互都根据 UUID 来操作也可以达到目的 |
 | 40 baleeny 2023-07-12 11:13:52 +08:00 楼上都误会楼主了，楼主说 name 大家以为是名字，楼主说 name 是唯一的，那不就是跟 uuid ，username 一个意思吗，可以作为查询条件，唯一了有啥不可以的 |
| 41 darkengine 2023-07-12 11:16:40 +08:00 @baleeny 理解他的意思，其实是他们的后端觉得用 name 没问题，OP 觉得不规范。就像“我们的后端要求所有请求都用 POST”一样。 |
 | 42 jstony 2023-07-12 11:19:41 +08:00 @baleeny +1 ，前提是 op 头够铁，能确保 name 字段唯一且不会变更，有一天产品经理说 name 要可以修改，你一定要坚持住不同意，就是老板来了，捅破天 name 也不能改，老板问为什么不能改，心里默默骂自己当初为什么那么中二。 |
 | 43 Esen 2023-07-12 11:21:56 +08:00 反正能用就行，我们主打的就是一个怎么方便怎么来，前后端和气 |
| 44 ktqFDx9m2Bvfq3y4 2023-07-12 11:22:33 +08:00 @darkengine UUID 会导致多一次查询，这也是我之前的方案。后来我看到 HashID 后就改进了。 |
 | 45 chuck1in 2023-07-12 11:25:36 +08:00 前端要用那个 id 来做那种循环组件的 index 的。 |
 | 49 fiypig 2023-07-12 14:07:36 +08:00 id 比字符串效率多了 |
 | 50 tool2d 2023-07-12 14:42:57 +08:00 我专门写了一个基于字符串 key 的搜索引擎，好处是对于只读数据筛查效率很高。 坏处是对于经常变动的数据集，老是重建索引就比较麻烦了。 |
Select Language