@billlee 这可不一定，你这么说的话就等于否定了 mysql 中 json 字段的意义了

key 不固定的需求非常多，mysql 有时常用的的 EAV 设计就是专门用来解决这一问题的。之后 mysql 的 json 字段也是用来解决这一问题： https://blog.huoding.com/2016/06/29/522

一天前的这个帖子实际上也是业务字段不确定，预计将来会有扩展需求的一个体现 https://www.v2ex.com/t/761703

对于这种结构不定的需求其实是部适合 sq 的，所以我才尝试学习 nosql 看看有没有更好的解决方法

这还用选？ EA 啊

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

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

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

@hjahgdthab750 图是真的 12 年的图，但是能成功完成 sql 注入是假的当年辟谣过，我觉得应该也没人会当真

这图主要还是好玩，从意想不到的角度进行 sql 注入

@Jirajine 看来你那访问不了 imgur，你说的号牌这图是我帖子的第二张图

@liprais 这里有个老实人......

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

没有，这个功能是系统层面支持的，不单单是浏览器的问题

单独一个 article_tag_relationship 表啊，就两个 column
article_id | tag_id

这样一个表你写 sql 语句还难吗

ORM 处理多对多关系也都是这样的

@generic 啊，那岂不是意味着每次改完 Dockerfile 之后就必须得重新手动 build 镜像才行

@301 基本移动都是上下行对等

@coolcoffee projector 的原生客户端里我看到了 ffmpeg.dll 和 vulkan-1.dll ， 嗯。。。。。

发现个影响使用的重大问题 —— 不能使用任何输入法

看了下 issue，几个月前就有人发了 IME 的 issue 还没解决，估计还得等个半年多才能用，先撤了继续用 xserver 在 wsl2 里跑着吧，离替换的路还很远

体验了下，直接能使用本地原生 IDEA 配置文件我是没想到的，迁移 0 成本这个给个好评

projector 可能还是原生运行比较好，docker 部署这个似乎很美好，但是我想了下不对，你光有 docker 部署的 IDEA 不能用啊，开发需要用到各种语言的 SDK，还有开发需要用到的包怎么办。写着 Dockerfile 给镜像里装 SDK 和各种包吗。。。。这样的话添加删除包，或者升级包的话，不得每次都要更新 Dockerfile 然后停掉原本的容器，重新生成镜像。。。。

我就奇了怪了，lz 你这需求现在的新 firefox 也能做到啊，直接回 firefox 不就好了

@anonymous256 我可以设置成左键单击后在新标签打开的话，凭什么去按那个难按的要死的中键呢

有的人真的是，装修是要管你房子十几几十年的事，居然拿现在的“我觉得够用”来考虑，不说别的，等今后家庭宽带普及 1Gbps 带宽的时候有得你们后悔的（别觉得不可能，4M 宽带网发展到现在才几年？过个十年 1Gbps 普及可以说是绝对的，不说别的日本这边民用就已经基本普及 1GBbps 宽带了，上下行对等。还嫌不够的话还有差不多价格提供 10Gbps 民用宽带的，不布有线承担得起这带宽吗）

然后既然考虑到十年后，那么布光纤是肯定要的。光纤这么便宜的东西，几百块就能买几百米提前布好有很高成本吗？至于光纤的其他设备又没让你现在就买，等今后光纤普及了再买不就行了