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

https://i.loli.net/2021/大带宽服务器03/15/dnpyGJEbXekCr51.png
我司货品表都有 30 个

erp 表

见过一些 Sass 系统,为了扩展,少改系统少更新,attr1,attr2.....attrN,挺好用的(手动狗头)

我们这 对接 cdc 的 那文档像这种字段 一个接口里面有 30 多个

不懂就问：千万的表加个字段会咋滴？
就数据库而言，千万挺小的吧

少见多怪

这很正常，使用第三方服务的时候，这种额外预留的字段给客户

PostgreSQL 的 jsonb 是真好用呀，性能也不差。

有时候可以做为动态字段设计，比如设计一个 product 表，product 的 custom_field 所代表的意义会根据分类变化。
又比如 crm 的 custom 字段，很多都是终端用户自定义的，这时候可能就是 contact.custom_field1,contact.custom_field2 这样的命名。


Mysql online DDL 不锁表增加字段和索引方法 https://c4ys.com/archives/1943

关系型有这种也太正常了。还有这种设计也从来不是什么不合理的设计。
就和数据库理论学习各种范式，而实际数据库设计有冗余字段一样。

同学～盲表 了解一下

数据库设计上是有这种冗余字段的设计，自有它的合理性

这根本不算什么
自从我接触了一个用 mysql 当报表的事业单位，我已经释然了。

你是沒見過 上百個備註字段的吧？

这个是 扩展字段吧! 不同业务系统对接都加一个 然后就

对千万级，上亿级的表增加字段，可能会卡上几十秒到几分钟

又不是不能用.JPG


66666

我们这边中台就有这种表。 你突然接入感觉挺突然的

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

楼主少见多怪了。

拓展字段 用 Json 一个 feature 字段 就够了，不用十个吧 ...
预留字段 数据格式不一定能用吧？可能还是要加新字段


什么叫预留，就是基于当前事实，预估在未来会发生某件事，而提前留出空间。
所以这种操作必然要基于其所在的业务场景来做预留，没必要纠结这个 case 中由于全都是字符类型未来会不会不满足需求，更没必要去推断其业务发展。
另外就算未来非加字段不可也没什么的，预留只是基于经验判断尽可能减少在未来变动的成本而已，并不是银弹。

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

看到你惊了，我惊了

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

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

这种冗余字段设计在 2000 年前后的金蝶、用友、ERP 中还挺常见的。
那时大家使用关系数据库，报表或者表单通过中间映射表甚至是语言层动态映射。
为了扩展很多事实表都会做类似处理。
你要以 2021 年眼光来看，有 MongoDB 、json types，那确实挫。
没办法，很多时候手上有个锤子就看什么都是钉子。

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

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

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

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

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

基操罢了

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

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

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