这是一个创建于 1739 天前的主题，其中的信息可能已经有所发展或是发生改变。
 | 1 fengxianqi 2021-03-15 11:05:33 +08:00  19 别笑，任何程序的设计都有其历史原因 |
 | 2 66beta 2021-03-15 11:05:38 +08:00 说不定人家就是碰到了什么特殊的业务场景，有时候研发部门就是这么卑微 |
 | 3 weizhen199 2021-03-15 11:06:21 +08:00 也不奇怪吧，我这 db 里的 log 表我也留了 8 个空字段 |
 | 4 psirnull 2021-03-15 11:07:22 +08:00 1 这有什么笑的，说明保密意识优秀 |
 | 5 sagaxu 2021-03-15 11:07:59 +08:00 via Android 十个领导一人一段批注 |
6 no1xsyzy 2021-03-15 11:09:30 +08:00 2 见过 field41 field42 这样的 其实需要的是一个 MongoDB |
 | 7 dethan 2021-03-15 11:10:54 +08:00 via Android 真的要看业务场景，有时候开发权限过低，连新增字段说不定都要层层审批的.... |
 | 8 MilkShake 2021-03-15 11:13:35 +08:00 我见过备用字段更多的时候 |
 | 9 egen 2021-03-15 11:15:40 +08:00 12 这种一看就是老手呀 |
 | 10 huxins 2021-03-15 11:16:34 +08:00 erp 这类这些很常见 |
 | 11 nickyang897897 2021-03-15 11:17:46 +08:00 1 笑啥，都是做一天和尚，撞一天钟，何必那么计较呢？ |
 | 12 bertonzh 2021-03-15 11:20:51 +08:00 1 扩展性强 |
 | 13 drunkdog 2021-03-15 11:21:43 +08:00 觉得害行！ |
 | 14 fkdtz 2021-03-15 11:23:35 +08:00 2 有些系统重构时，为了避免再次踩入频繁变动的坑，是会预留一些字段的。踩坑踩怕了，知道疼了。 |
 | 15 wangxiaoaer 2021-03-15 11:27:54 +08:00 多个备注字段有啥问题吗？ |
 | 16 anzu 2021-03-15 11:30:07 +08:00 以前在半个国企的时候经常见。当项目交付后，客户之后还有其它小需求，此时只需要改程序代码，而不必改数据库结构，甚至有的数据库数据涉及商业机密不让看更别说改，万一改乱就惨了。 |
 | 17 qjbcnrs 2021-03-15 11:45:41 +08:00 狗东的文档  |
 | 18 Renco 2021-03-15 11:46:27 +08:00 虽然但是，感觉没什么问题 |
 | 19 nekoneko 2021-03-15 11:47:46 +08:00 很正常,遇到对接的时候你就知道有多大作用了 |
 | 20 preach 2021-03-15 11:48:57 +08:00 如果是扩展字段无可厚非 |
 | 21 xuanbg 2021-03-15 11:49:58 +08:00 3 @no1xsyzy 其实 json 字段也可以。如果不是祖传，设计这种无意义备用字段的程序员，技术视野之狭隘，真是令人无语 |
 | 22 PeterYang1996 2021-03-15 11:51:00 +08:00 @sagaxu 有道理，哈哈哈 |
 | 23 FucUrFrd 2021-03-15 11:52:05 +08:00 via Android 备注还是备用？ |
 | 24 quicknight 2021-03-15 11:52:23 +08:00 1 楼主新手吧 |
 | 25 dexterzzz 2021-03-15 11:52:35 +08:00 via Android erp 领域的基本功能，拓展属性 /弹性域 |
 | 26 liuzhaowei55 2021-03-15 11:58:11 +08:00 via iPhone 2 新建表必有 extra，remark 两个字段 开发就是来填坑的 |
 | 27 sun1991 2021-03-15 11:59:33 +08:00 哎, 你见同一个字段 field10 的不同行里的值, 在不同代码段里代表完全不同意思么? |
 | 28 tabris17 2021-03-15 12:03:12 +08:00 肯定是个被产品经理坑苦的开发 |
 | 29 lusi1990 2021-03-15 12:12:03 +08:00 用用 db2 就知道了 |
 | 30 redtea 2021-03-15 12:18:01 +08:00 3 千万条级别的表，加个字段试试如何不影响生产环境。 |
 | 31 BeautifulSoap 2021-03-15 12:19:37 +08:00 via Android @xuanbg 用 json 可还行 json 字段性能非常差，几十万，百万数据量的时候 query 就非常慢了，对于需要搜索的内容不应该用 json 字段 |
 | 32 zengming00 2021-03-15 12:22:43 +08:00 用 mongodb 不用这么设计，用 sql 的话其实挺正常的，数据量大了的时候突然要加个字段你就知道了 |
 | 33 no1xsyzy 2021-03-15 12:38:34 +08:00 @xuanbg 那个系统是 SQL Server 2014，查了下好像 2016 才有 JSON Support…… 不过确实可能是乙方外包的祖传。 顺便，推荐各位持 get-stuff-done 哲学的，去用用 Ponylang （开始推荐奇怪的语言） |
 | 34 Vegetable 2021-03-15 12:41:31 +08:00 这个的确有点好笑，但是，更搞笑的多了去了。 |
| 35 xuanbg 2021-03-15 13:09:21 +08:00 @BeautifulSoap 这种意义不明，与逻辑无关的内容也不会用来查询的吧。再说，field1 、field2 这样的字段能写条件查询？ |
 | 36 Hallelu 2021-03-15 13:12:02 +08:00 正常现象，做 erp 的时候，经常都会预留几个字段来防止不时之需，extra_1,extra_2..... |
 | 37 jasonkayzk 2021-03-15 13:13:45 +08:00 这有啥搞笑的。 我刚入职的时候，看到同事直接 select from table_1, table_2，还跟我说这叫联表操作，我直接震惊！ |
 | 38 Hystrix13 2021-03-15 13:36:25 +08:00 这有啥搞笑的 你不会预留字段吗 后面需求要加你咋办 |
 | 39 buxudashi 2021-03-15 13:52:08 +08:00 恰恰是有经验的程序员干的！ |
 | 40 iyaozhen 2021-03-15 13:52:38 +08:00 很多原因吧 虽然有点 low 1. MySQL 5.7 才支持 json，现在公司还只到 5.6 。存成 json 拿出来用，又给业务增加复杂性 2. 换其它数据库成本更大 3. 表很大，在线 DDL 有风险，所以预留个 |
 | 41 JackPJ 2021-03-15 13:56:44 +08:00 作为一个产品，见过很多 toB 的系统预留扩展字段，就是为了解决后续需求可能在表中插入新字段的需求，单表数据量比较大。不知道有无更好的解决方案给大伙分享分享 |
 | 42 janxin 2021-03-15 13:59:20 +08:00 这都是怪没给时间 23333 |
 | 43 cslive 2021-03-15 13:59:40 +08:00 数仓里的吧，没有备注是看不懂的 |
 | 44 knightdf 2021-03-15 14:21:07 +08:00 没看过文档么？这有什么好笑的 |
 | 45 tankren 2021-03-15 14:25:20 +08:00 很正常吧 这个备注是 comment 的翻译 中文是字段的描述 而不是说中文是该字段的备注 |
 | 46 yanulg 2021-03-15 14:33:15 +08:00 没见识的人还真多啊，等数据上千万了你也改表结构？ |
 | 47 a719031256 2021-03-15 14:36:36 +08:00 才 10 个，我同类型的字段加了 30 个，没法，业务需求 |
 | 48 someonedeng 2021-03-15 14:37:26 +08:00 不得已而为之 |
 | 49 ClarkAbe 2021-03-15 14:40:11 +08:00 via Android 建设银行的代扣也有....备注 1 备注 2 |
 | 50 kknd22 2021-03-15 14:40:20 +08:00 ERP 的弹性域 预留的 |
| 51 BeautifulSoap 2021-03-15 14:43:03 +08:00 @xuanbg 用 field1，field2 这种名称很大可能是最开始预留的字段。预留字段不知道将来干嘛那肯定就是 1，2，3，4 这样名字排下去了，所以这种将来可能用到的字段也有很大可能是需要检索的。json 字段是真的只适合用来存和取，一旦要搜的话速度慢到让人怀疑人生 当然不预留字段根据需要添加字段是最好的，但是对于生产环境里的数据库的操作，往往不是程序员自己能决定的 |
 | 52 meeop 2021-03-15 14:43:51 +08:00 这有啥,我 mysql 还预留了 15 个备用字段呢,这样后续加字段加索引的时候就不用改表改 po 改查询,只要简单把新字段 set 一下就完成了 |
 | 53 RRRoger 2021-03-15 14:48:19 +08:00 这个很常见啊 ~ |
 | 54 tairan2006 2021-03-15 15:10:41 +08:00 @BeautifulSoap 现在 json 可以加索引了。。。 |
 | 55 treemonster 2021-03-15 15:10:53 +08:00 这种设计很正常，不懂问题在哪里。。 |
 | 56 shawn102400 2021-03-15 15:22:54 +08:00 2 年轻人见识少不懂事，稍微见识过几个老点的大型系统都不至于浅薄。 |
 | 57 Asuka0947 2021-03-15 15:25:53 +08:00 没事我见过连表名称都是 123456 的很正常 |
 | 58 ixuelei 2021-03-15 15:32:26 +08:00 不要瞎猜了，这是上面规定要这样弄的。 |
 | 59 BeautifulSoap 2021-03-15 15:32:41 +08:00 @tairan2006 看了下文档，还真是。。。。不过只能针对 json 字段中特定的键创建索引，如果业务字段毕竟固定的话的确可以了。不过如果 json 里存的字段很多变的话，还是不太合适 |
 | 60 isnullstring 2021-03-15 15:41:51 +08:00 这种应该是设计表时候提前预留的吧 |
 | 61 jing8956 2021-03-15 15:46:00 +08:00 via Android 我见过没上线的产品，.net core 3.1，用了 Entity Framework Core 也还这么整的，都这样了还这么整能有什么原因，不就是“增加学习成本”么 |
 | 62 neptuno 2021-03-15 16:02:37 +08:00 见过一个政府项目，sfzh-身份证号，jhz-结婚证，jyxkz-经营许可证 |
 | 63 juneva 2021-03-15 16:06:01 +08:00 前公司都是 5 个 remark 起步 |
 | 64 YulChigga 2021-03-15 16:08:58 +08:00 文件夹 123qwe 的都有 |
 | 65 chenny3 2021-03-15 16:10:52 +08:00 之前在 PCB 行业龙头国企待过，像这样预留字段的表时常可见 |
 | 66 leon9986666 2021-03-15 16:25:00 +08:00 需要加字段的时候这样子还是挺方便的 |
 | 67 PopRain 2021-03-15 16:26:32 +08:00 有什么好笑的，如果要做数据复制、或者数据库不能轻易锁表，这样设计算超前考虑了，算考虑的比较全面好不好 |
 | 68 efaun 2021-03-15 16:29:17 +08:00 @quicknight #24 +1 还是太年轻了 |
 | 69 ytmsdy 2021-03-15 16:30:26 +08:00 正常操作，多接几个屎山项目，就知道这些备注字段的重要性了！ |
 | 70 wangyzj 2021-03-15 16:55:52 +08:00 1  |
 | 71 zw1one 2021-03-15 16:58:00 +08:00 项目上线后，修改数据库字段成本过高吧。可能是技术成本，但通常是等领导流程审批的时间成本 |
 | 72 lixintcwdsg 2021-03-15 17:02:11 +08:00 这就是此接口牛逼，什么需求都接得下不用改 API 的意思，你要佩服这个设计人。 |
 | 73 shoushi 2021-03-15 17:13:53 +08:00 一般都会预留几个字段，用来应对不同客户的需求还不用改主分支代码 |
 | 人家可能是 package 开发的公司，这种很正常。 |
 | 75 liangsaifei 2021-03-15 18:03:13 +08:00 @zhongjun96 其实这样也挺好。。毕竟起英文名字更头大。 |
 | 76 labulaka521 2021-03-15 18:41:46 +08:00 学习了 |
 | 77 ragnaroks 2021-03-15 19:00:04 +08:00 见过一个这种的 php 写的 cms，自带几个主题，竟然可以一处不改，就能从企业门户变成信用卡收集站，还能变论坛 |
 | 78 helloworld2076 2021-03-15 19:40:48 +08:00 via iPhone 上家公司，如果数据库设计没有十个 rsv 字段，我会把数据库设计退回去。 |
 | 79 nicebird 2021-03-15 19:49:49 +08:00 这是备用的，实际上是种解耦。实际用途和字段名分离，依靠注释重新建立关系。 |
 | 80 young1lin 2021-03-15 19:52:09 +08:00 @zhongjun96 让我想起了我第一家公司，什么 OD01，OD07，KS01，ks36，没有注释，根本看不懂 |
 | 81 ruoxie 2021-03-15 19:55:54 +08:00 前两周刚遇到过，备注 1，备注 2，备注 3 。。。没人能确定有多少，本来是直接存 json 字符串，然后产品要求能精确导出备注几 |
 | 82 tesguest123 2021-03-15 19:57:12 +08:00 via iPhone 题主一看就是年轻的程序员，一般我都是预留 5 个以上的无用字段，数据表具有扩展性。 |
| 83 tesguest123 2021-03-15 19:57:42 +08:00 via iPhone @tesguest123 要不然太累了 |
 | 84 aQI9F2Sb927YPj7I 2021-03-15 20:02:10 +08:00 如果你看到了这个接口文档后，选择了拒绝对接，那么这个帖子还有一些营养。 |
 | 85 lj2016 2021-03-15 20:06:38 +08:00 via iPhone 这种太正常了，后续有增加会很方便 |
 | 86 gam2046 2021-03-15 20:07:22 +08:00 个人觉得这个设计没什么问题，基本上预留一些升级的空间。上线一段时间后，新增需求，改数据库是非常要命的一件事。而且正规的流程，开发人员很可能没有权限操作数据库，还需要 DBA 的配合（甚至行政手段的接入），生产环境飞针走线，太可怕了。 至于可读性差，确实没什么办法，预留接口，天知道到时候甲方爸爸会提出什么需求来。全靠文档支撑。 |
 | 87 vinsony 2021-03-15 20:20:58 +08:00 你太年轻了。我有 str_1 2 3 4 5 、int_1 2 3 4 5........ |
 | 88 levelworm 2021-03-15 20:34:17 +08:00 给你看个才在 reddit 上看到的，和你是反的。人家是 30 个字段，29 个是反的，还有 1 个把其他 29 个字段的内容全囊括进去了。。。 Every database entry consisted of: Column 1: $itemID, $stuff, $morestuff, $evenmorestuff ... Columns 2-30: NULL |
 | 89 aaronlam 2021-03-15 21:12:50 +08:00 之前呆过的国企内开发的系统也是预留了很多这些弹性域 |
| 91 tairan2006 2021-03-15 22:49:09 +08:00 你们吵个球…根据《阿里巴巴 Java 编程手册》里面数据库部分，明确说明： 禁止在表中建立预留字段 预留字段的命名很难做到见名识义 预留字段无法确认存储的数据类型，所以无法选择合适的类型 对预留字段类型的修改，会对表进行锁定，修改字段类型的成本往往大于增加 MySQL5.6 之后加列就可以有条件的避免锁了，8.0 之后就更高效了…所以楼上嘲笑楼主年轻的，做的业务比阿里流量还大？ |
 | 92 MaiKuraki 2021-03-15 22:57:57 +08:00 这个图床太恶心了，不能直接显示图片，还要点击才能显示 |
 | 93 boshok 2021-03-15 23:29:04 +08:00 2 @tairan2006 什么都跟阿里比？针对不同业务采取不同方式有问题吗？谁都是互联网企业？也都是用 MYSQL ？ |
 | 94 iamv2er 2021-03-16 00:35:09 +08:00 via iPhone 刚好碰到这个场景 预留后面直接改名快一点 要不然数据库数据很多 会影响生产环境 |
 | 95 msg7086 2021-03-16 01:02:44 +08:00 @tairan2006 要真能做到比阿里流量还大，体量这么大了就可以自己研发数据库系统了，还需要预留字段？ 阿里背后几十万台服务器的算力，你做外包给甲方也整上几千台服务器吗。 |
 | 96 Iamnotfish 2021-03-16 01:33:16 +08:00 那你们是没见过传统行业开发的需求，我见过一个 POS 系统，字段全是 F01,F02,F03 这种，一直到 F9999 。连字段的 WIKI 都没有，全靠猜。 |
 | 97 mikael 2021-03-16 07:18:09 +08:00 1 可以看出当初设计这表的人怀着远大的目标，已经知道这个表以后肯定还要承受更多的字段 |
 | 98 diyisoft 2021-03-16 07:54:13 +08:00 “少见多怪”（褒义），哈哈哈 有些场景是需要这样的。 |
 | 99 uilvn 2021-03-16 08:17:52 +08:00 1 salesforce 底层表都是这么设计的。所有的表字段都是占位符，实际内容由 meta 表解释。 |
 | 100 bwd1991 2021-03-16 08:33:47 +08:00 1 @jasonkayzk 加上 where 条件还真是内联查询 |
Select Language