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

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

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

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

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

十个领导一人一段批注

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

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

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

这种一看就是老手呀

erp 这类这些很常见

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

扩展性强

觉得害行！

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

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

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

狗东的文档

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

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

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

@sagaxu 有道理，哈哈哈

备注还是备用？

楼主新手吧

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

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

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

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

用用 db2 就知道了

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

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

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

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

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

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

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

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

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

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

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

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

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

这都是怪没给时间 23333

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

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

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

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

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

不得已而为之

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

ERP 的弹性域
预留的

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

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

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

这个很常见啊 ~

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

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

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

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

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

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

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

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

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

前公司都是 5 个 remark 起步

文件夹 123qwe 的都有

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

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

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

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

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

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

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

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

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

学习了

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

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

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

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

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

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

@tesguest123 要不然太累了

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

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

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

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

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

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

Every database entry consisted of:

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

Columns 2-30: NULL

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

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

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

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

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

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

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

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

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

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

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

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

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