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

[yasumoto]

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

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

[visonme]

这种设计其实在信息系统是很常见的，像老系统设计，或者存储一些不确定的属性字段时候都会使用，基于元数据那套成本高，小公司一般不会去这怎么干的，而且这类字段通常以展示为主

[ddup]

楼主少见多怪了。

[zjuster]

@preach 拓展字段 用 Json 一个 feature 字段 就够了，不用十个吧 ...

@weizhen199 @fkdtz 预留字段 数据格式不一定能用吧？可能还是要加新字段

[fkdtz]

@zjuster
什么叫预留，就是基于当前事实，预估在未来会发生某件事，而提前留出空间。

所以这种操作必然要基于其所在的业务场景来做预留，没必要纠结这个 case 中由于全都是字符类型未来会不会不满足需求，更没必要去推断其业务发展。

另外就算未来非加字段不可也没什么的，预留只是基于经验判断尽可能减少在未来变动的成本而已，并不是银弹。

[xumng123]

有啥，我的数据库已经 reserved2xx 了。各种奇葩没用的需求多了去了，过两天就没用了。reserved 可以循环利用。

[iddddg]

看到你惊了，我惊了

[wmhx]

最讨厌纵表了, 但很多时候没办法,比如产品属性,动态表单类的都是这种设计, 非常不好记, 但这也是一种设计.

[futamilk]

那你是见得少了 hhh
前段时间才遇到的，一个字段根据数据格式不同，需要分别解析为接近十种不同含义。就是因为预留字段不够用了

[wupher]

这种冗余字段设计在 2000 年前后的金蝶、用友、ERP 中还挺常见的。

那时大家使用关系数据库，报表或者表单通过中间映射表甚至是语言层动态映射。

为了扩展很多事实表都会做类似处理。

你要以 2021 年眼光来看，有 MongoDB 、json types，那确实挫。

没办法，很多时候手上有个锤子就看什么都是钉子。

[nicevar]

说实话，真的是少见多怪，你要是翻出以前的各种操作系统代码注释都能找到这样的

[seakingii]

数据表预留备用字段是常见的业务上的处理方式，有什么好笑的。动不动就笑话别人不是好心态。

[poorcai]

我觉得这很正常吧？这个不是现在要用的，是为了后面扩展的，一般有这种字段的，内部都会维护一个字段说明的文档。

[opengps]

早期项目用的生成工具太正常，改一次 sql 结构影响代码太多，重新生成还有不合意的地方，所以就只能用这个方法

[alfchin]

@xuanbg 还以为有啥优秀的解决方案，原来比靶子还不靠谱。。。

[tgich]

基操罢了

[catsoul]

基本操作，尤其是涉及到跨公司，跨部门那种项目的时候，这种预留是很常见的。

[CBS]

预留就预留，你发送给前端，这真的河里嘛？

[shawn102400]

@hyq 几分钟是想多了，没几个小时下不来。