今天对接的一个公司 看到接口文档我惊了

[yasumoto]

居然还有这种操作 备注字段 12345678910 （笑 cry ）

https://i.loli.net/2021/03/15/dnpyGJEbXekCr51.png

[fengxianqi]

别笑，任何程序的设计都有其历史原因

[66beta]

说不定人家就是碰到了什么特殊的业务场景，有时候研发部门就是这么卑微

[weizhen199]

也不奇怪吧，我这 db 里的 log 表我也留了 8 个空字段

[psirnull]

这有什么笑的，说明保密意识优秀

[sagaxu]

十个领导一人一段批注

[no1xsyzy]

见过 field41 field42 这样的
其实需要的是一个 MongoDB

[dethan]

真的要看业务场景，有时候开发权限过低，连新增字段说不定都要层层审批的....

[aaa5838769]

我见过备用字段更多的时候

[egen]

这种一看就是老手呀

[huxins]

erp 这类这些很常见

[nickyang897897]

笑啥，都是做一天和尚，撞一天钟，何必那么计较呢？

[bertonzh]

扩展性强

[drunkdog]

觉得害行！

[fkdtz]

有些系统重构时，为了避免再次踩入频繁变动的坑，是会预留一些字段的。踩坑踩怕了，知道疼了。

[wangxiaoaer]

多个备注字段有啥问题吗？

[anzu]

以前在半个国企的时候经常见。当项目交付后，客户之后还有其它小需求，此时只需要改程序代码，而不必改数据库结构，甚至有的数据库数据涉及商业机密不让看更别说改，万一改乱就惨了。

[zhongjun96]

狗东的文档

[Renco]

虽然但是，感觉没什么问题

[nekoneko]

很正常,遇到对接的时候你就知道有多大作用了

[preach]

如果是扩展字段无可厚非

[xuanbg]

@no1xsyzy 其实 json 字段也可以。如果不是祖传，设计这种无意义备用字段的程序员，技术视野之狭隘，真是令人无语

[PeterYang1996]

@sagaxu 有道理，哈哈哈

[FucUrFrd]

备注还是备用？

[quicknight]

楼主新手吧

[dexterzzz]

erp 领域的基本功能，拓展属性 /弹性域

[liuzhaowei55]

新建表必有 extra，remark 两个字段 开发就是来填坑的

[sun1991]

哎, 你见同一个字段 field10 的不同行里的值, 在不同代码段里代表完全不同意思么?

[tabris17]

肯定是个被产品经理坑苦的开发

[lusi1990]

用用 db2 就知道了

[redtea]

千万条级别的表，加个字段试试如何不影响生产环境。

[BeautifulSoap]

@xuanbg 用 json 可还行
json 字段性能非常差，几十万，百万数据量的时候 query 就非常慢了，对于需要搜索的内容不应该用 json 字段

[zengming00]

用 mongodb 不用这么设计，用 sql 的话其实挺正常的，数据量大了的时候突然要加个字段你就知道了

[no1xsyzy]

@xuanbg 那个系统是 SQL Server 2014，查了下好像 2016 才有 JSON Support…… 不过确实可能是乙方外包的祖传。

顺便，推荐各位持 get-stuff-done 哲学的，去用用 Ponylang （开始推荐奇怪的语言）

[Vegetable]

这个的确有点好笑，但是，更搞笑的多了去了。

[xuanbg]

@BeautifulSoap 这种意义不明，与逻辑无关的内容也不会用来查询的吧。再说，field1 、field2 这样的字段能写条件查询？

[Hallelu]

正常现象，做 erp 的时候，经常都会预留几个字段来防止不时之需，extra_1,extra_2.....

[jasonkayzk]

这有啥搞笑的。
我刚入职的时候，看到同事直接 select from table_1, table_2，还跟我说这叫联表操作，我直接震惊！

[Hystrix13]

这有啥搞笑的 你不会预留字段吗 后面需求要加你咋办

[buxudashi]

恰恰是有经验的程序员干的！

[iyaozhen]

很多原因吧 虽然有点 low
1. MySQL 5.7 才支持 json，现在公司还只到 5.6 。存成 json 拿出来用，又给业务增加复杂性
2. 换其它数据库成本更大
3. 表很大，在线 DDL 有风险，所以预留个

[JackPJ]

作为一个产品，见过很多 toB 的系统预留扩展字段，就是为了解决后续需求可能在表中插入新字段的需求，单表数据量比较大。不知道有无更好的解决方案给大伙分享分享

[janxin]

这都是怪没给时间 23333

[cslive]

数仓里的吧，没有备注是看不懂的

[knightdf]

没看过文档么？这有什么好笑的

[tankren]

很正常吧 这个备注是 comment 的翻译 中文是字段的描述 而不是说中文是该字段的备注

[yanulg]

没见识的人还真多啊，等数据上千万了你也改表结构？

[a719031256]

才 10 个，我同类型的字段加了 30 个，没法，业务需求

[someonedeng]

不得已而为之

[ClarkAbe]

建设银行的代扣也有....备注 1 备注 2

[kknd22]

ERP 的弹性域
预留的

[BeautifulSoap]

@xuanbg 用 field1，field2 这种名称很大可能是最开始预留的字段。预留字段不知道将来干嘛那肯定就是 1，2，3，4 这样名字排下去了，所以这种将来可能用到的字段也有很大可能是需要检索的。json 字段是真的只适合用来存和取，一旦要搜的话速度慢到让人怀疑人生

当然不预留字段根据需要添加字段是最好的，但是对于生产环境里的数据库的操作，往往不是程序员自己能决定的

[meeop]

这有啥,我 mysql 还预留了 15 个备用字段呢,这样后续加字段加索引的时候就不用改表改 po 改查询,只要简单把新字段 set 一下就完成了

[RRRoger]

这个很常见啊 ~

[tairan2006]

@BeautifulSoap 现在 json 可以加索引了。。。

[treemonster]

这种设计很正常，不懂问题在哪里。。

[shawn102400]

年轻人见识少不懂事，稍微见识过几个老点的大型系统都不至于浅薄。

[Asuka0947]

没事我见过连表名称都是 123456 的很正常

[ixuelei]

不要瞎猜了，这是上面规定要这样弄的。

[BeautifulSoap]

@tairan2006 看了下文档，还真是。。。。不过只能针对 json 字段中特定的键创建索引，如果业务字段毕竟固定的话的确可以了。不过如果 json 里存的字段很多变的话，还是不太合适

[isnullstring]

这种应该是设计表时候提前预留的吧

[jing8956]

我见过没上线的产品，.net core 3.1，用了 Entity Framework Core 也还这么整的，都这样了还这么整能有什么原因，不就是“增加学习成本”么

[neptuno]

见过一个政府项目，sfzh-身份证号，jhz-结婚证，jyxkz-经营许可证

[juneva]

前公司都是 5 个 remark 起步

[YulChigga]

文件夹 123qwe 的都有

[chenny3]

之前在 PCB 行业龙头国企待过，像这样预留字段的表时常可见

[leon9986666]

需要加字段的时候这样子还是挺方便的

[PopRain]

有什么好笑的，如果要做数据复制、或者数据库不能轻易锁表，这样设计算超前考虑了，算考虑的比较全面好不好

[efaun]

@quicknight #24 +1 还是太年轻了

[ytmsdy]

正常操作，多接几个屎山项目，就知道这些备注字段的重要性了！

[wangyzj]

[zw1one]

项目上线后，修改数据库字段成本过高吧。可能是技术成本，但通常是等领导流程审批的时间成本

[lixintcwdsg]

这就是此接口牛逼，什么需求都接得下不用改 API 的意思，你要佩服这个设计人。

[shoushi]

一般都会预留几个字段，用来应对不同客户的需求还不用改主分支代码

[cgpiao]

人家可能是 package 开发的公司，这种很正常。

[liangsaifei]

@zhongjun96 其实这样也挺好。。毕竟起英文名字更头大。

[labulaka521]

学习了

[ragnaroks]

见过一个这种的 php 写的 cms，自带几个主题，竟然可以一处不改，就能从企业门户变成信用卡收集站，还能变论坛

[helloworld2076]

上家公司，如果数据库设计没有十个 rsv 字段，我会把数据库设计退回去。

[nicebird]

这是备用的，实际上是种解耦。实际用途和字段名分离，依靠注释重新建立关系。

[young1lin]

@zhongjun96 让我想起了我第一家公司，什么 OD01，OD07，KS01，ks36，没有注释，根本看不懂

[ruoxie]

前两周刚遇到过，备注 1，备注 2，备注 3 。。。没人能确定有多少，本来是直接存 json 字符串，然后产品要求能精确导出备注几

[tesguest123]

题主一看就是年轻的程序员，一般我都是预留 5 个以上的无用字段，数据表具有扩展性。

[tesguest123]

@tesguest123 要不然太累了

[conghuiwang]

如果你看到了这个接口文档后，选择了拒绝对接，那么这个帖子还有一些营养。

[lj2016]

这种太正常了，后续有增加会很方便

[gam2046]

个人觉得这个设计没什么问题，基本上预留一些升级的空间。上线一段时间后，新增需求，改数据库是非常要命的一件事。而且正规的流程，开发人员很可能没有权限操作数据库，还需要 DBA 的配合（甚至行政手段的接入），生产环境飞针走线，太可怕了。

至于可读性差，确实没什么办法，预留接口，天知道到时候甲方爸爸会提出什么需求来。全靠文档支撑。

[vinsony]

你太年轻了。我有 str_1 2 3 4 5 、int_1 2 3 4 5........

[levelworm]

给你看个才在 reddit 上看到的，和你是反的。人家是 30 个字段，29 个是反的，还有 1 个把其他 29 个字段的内容全囊括进去了。。。

Every database entry consisted of:

Column 1: $itemID, $stuff, $morestuff, $evenmorestuff ...

Columns 2-30: NULL

[aaronlam]

之前呆过的国企内开发的系统也是预留了很多这些弹性域

[xwcs]

@young1lin 医疗软件这块太多这种字段了

[tairan2006]

你们吵个球…根据《阿里巴巴 Java 编程手册》里面数据库部分，明确说明：

禁止在表中建立预留字段
预留字段的命名很难做到见名识义
预留字段无法确认存储的数据类型，所以无法选择合适的类型
对预留字段类型的修改，会对表进行锁定，修改字段类型的成本往往大于增加

MySQL5.6 之后加列就可以有条件的避免锁了，8.0 之后就更高效了…所以楼上嘲笑楼主年轻的，做的业务比阿里流量还大？

[MaiKuraki]

这个图床太恶心了，不能直接显示图片，还要点击才能显示

[boshok]

@tairan2006 什么都跟阿里比？针对不同业务采取不同方式有问题吗？谁都是互联网企业？也都是用 MYSQL ？

[iamv2er]

刚好碰到这个场景 预留后面直接改名快一点 要不然数据库数据很多 会影响生产环境

[msg7086]

@tairan2006 要真能做到比阿里流量还大，体量这么大了就可以自己研发数据库系统了，还需要预留字段？
阿里背后几十万台服务器的算力，你做外包给甲方也整上几千台服务器吗。

[Iamnotfish]

那你们是没见过传统行业开发的需求，我见过一个 POS 系统，字段全是 F01,F02,F03 这种，一直到 F9999 。连字段的 WIKI 都没有，全靠猜。

[mikael]

可以看出当初设计这表的人怀着远大的目标，已经知道这个表以后肯定还要承受更多的字段

[diyisoft]

“少见多怪”（褒义），哈哈哈
有些场景是需要这样的。

[uilvn]

salesforce 底层表都是这么设计的。所有的表字段都是占位符，实际内容由 meta 表解释。

[bwd1991]

@jasonkayzk 加上 where 条件还真是内联查询