@Justin13 最近学领域驱动设计，有点自己拙见

你说的沟通能力，不同团队不同人的沟通能力都不一样，领域驱动开发里就是为了减少不同人团队之间的沟通障碍，才不厌其烦地(甚至到了啰嗦的地步)强调开发中必须坚持使用领域模型和通用语言进行交流(UBIQUITOUS LANGUAGE)

因为领域模型和通用语言是领域专家和开发人员共同制定的，本身就自带了领域知识，并且坚持使用它们能大幅减少不同团队和人之间的沟通成本，减少误解


戴森球团队之所以开发如此顺畅，我觉得一个解释是因为他们大部分人都经验非常丰富，甚至可能团队中很多人都算是领域专家。他们都了解这个领域也了解程序开发，领域知识无需过度沟通。自己即是设计者又是开发者（虽然各有分工），因此团队内就很轻松地能统一领域模型和通用语言，从而提高开发效率

@zhangysh1995 你别说，这方法对我来说还挺好用的，之后嘴唇也溃疡几次，也是挺久好不了，电动牙刷刷几下马上有效果。估计是电动牙刷的振动和摩擦能很好去除溃疡处坏死的细胞和病菌吧

再次申明，仅供参考

曾经有段时间下嘴唇一处溃疡，一星期都没好转迹象，然后我晚上刷牙时突发奇想，刷牙时就着牙膏忍着痛用电动牙刷对着溃疡的地方刷了又刷（那叫一个痛），然后第二天起床发现溃疡居然好了挺多，然后第二天晚上再来一次溃疡好了一半多了，之后溃疡就很快好了

俗话说人与人的体质不能一概而论.jpg 我的经验仅供参考

@tctc4869
windows 的原生容器是要 win10 才支持，你 win7 用不了。所以要么换 win10，要么就乖乖用虚拟机，对 win7 来说没得选

你想用 docker 跑 linux 下的程序的话，就没法越过虚拟机，wsl2 也是轻量虚拟机


windows 其实也是有原生的容器的，并且 docker for windows 也能切换成 windows containers，只不过 windows 下的容器自然也只能跑 windwos 的程序
https://docs.microsoft.com/en-us/virtualization/windowscontainers/about/

@ch2 看了下 clickhouse 的文档，似乎 clickhouse 和 mysql 一样需要定义表结构的样子？数据的结构不定的话没法像 mongodb 一样轻松添加删除键吧

@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 基本移动都是上下行对等