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