疑问贴：大佬们在什么情况下，会考虑数据库字段存 json

[Visitor233]

RT ，新项目（ C#，postgresql ）还在编写中，有部分配置信息是用 json 存在表字段里，因为每个单独的配置内容部分不一样。

写着写着发现，经常要拿 json 里的部分一样的数据做查询条件，联表条件，分组条件。pg 有 json 函数好操作 json ，但又不想增加维护 sql 的工作，大家都写的 ef 或者 linq 。

跟组长讨论后，决定是放出来做单独的字段。

存 json 实用性受限呐。

[qwerthhusn]

有些东西，你确定以后永远不可能作为条件查询的，尤其是那些更新很少或者会作为一个整体进行更新，字段也不需要解析作为计算条件的，其实都可以作为 json 存下来
客户端需要的时候，直接丢出去即可。

[RangerWolf]

赞同二楼的说法，仅仅只是存储，几乎没有查询、搜索之类的需求

[clockwork1122]

刚好有同样的业务场景，数据库有个专门的表存配置信息，然后一个字段 key 作为区分不同配置，然后就六七个 value 字段表达配置信息。

[Biggoldfish]

找个支持处理 semi structured data 的数据库，然後想存就存呗，最多用到的时候要带上 json path 而已

[BeautifulSoap]

LZ 这个问题，在我写公司的 CMS 的时候就遇到了，说白了 json 字段除了单纯的存储，存在的另一个非常重要的作用就是为了让 mysql 这样的 RDS 关系型数据库，能拥有像 mongodb 这样的 nosql 数据库能力

在 json 字段出现之前，想让 mysql 拥有这种能力只能使用 EAV 模型：简单介绍可以看看这个文章 https://blog.huoding.com/2016/06/29/522

[infun]

存快照信息用，其它极少

[shylockhg]

不需要表现 json 结构化语义时

[sunrain]

自定义埋点

[tranfer]

拿 RDB 凑活着存日志的时候, 存多了方便整体倒到 hive 去

[timethinker]

字段不需要被用于 SQL 查询过滤的时候，仅用于程序处理，就跟存二进制的数据一样，但不适用于 OLAP 系统。

读写分离不仅仅只是在代码层面，而应该体现在整体的架构层面。例如游戏，存数据库只是为了存档，查询玩家数据只会用到 player_id 这一个字段，所有的操作都在内存完成，数据库存 JSON 或者二进制都没问题，甚至有时候都不需要数据库，开发测试的时候用文件来替代也是没问题的。

但如果需要查询玩家的统计数据，应当抽离出来使用专门的查询分析系统，存储使用 ES 或者各种日志仓库系统。

[4771314]

不需要做条件查询而且数据的字段比较多的情况，比如：活动配置

[fxxkgw]

只存储，不涉及查询

还要考虑 json 和 dict/map 转化的问题，这个可以通过重定义、语法糖等方式解决。

[2i2Re2PLMaDnghL]

@tabris17 整存整取的话，json 相比 text 有优势吗

[meiyoumingzi6]

用起来爽的一批, 维护起来就蛋疼了

[unclemcz]

很多第三方数据采集的时候（比如爬虫）存 json 会更方便，可以不用太担心后期源数据结构不可控的变动。

[Visitor233]

@clockwork1122 你这结构有点意思哦

[Visitor233]

@qwe520liao 长见识了，谢谢！

[CoderLife]

snapshot 这种得存 json

[loading]

有一次帮朋友用一两个小时二开的时候，不想改数据库，说要多加一个字段。
我一看只有一个 asp 文件，我把人员性别那里改了。

[jorneyr]

配置信息我喜欢存 JSON ，字段不单独查询的数据也考虑存 JSON