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

[Visitor233]

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

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

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

存 json 实用性受限呐。

[wxw752]

说到这我就想喷我们部门经理，前期数据库存储非让我们怎么快怎么来，后期贼痛苦。
很多年不敲代码只懂那些上个十年的技术，偏偏还喜欢对项目进行一番指导，说也不听...
回想起来上一个微操大师还是蒋*石。

[dayeye2006199]

pg 的 json 和二进制 jsonb 是可以建索引的。所以作为查询条件、连表条件都是没问题的。技术其实在进步，大家可以试着尝试一下这些数据库的新功能。

我们现在的新项目都是上 PG ，关系型非关系型都是一套系统。全文索引也是用 pg 。后台的数据库选型异常的简单。
（但我们不是做电商这样的高并发项目的，所以不清楚规模上去了会怎么样；在初创阶段，一个功能丰富的数据库能帮助到开发速度很多）

[qdcanyun]

赞同 @binux 的观点

[nziu]

赞同 @dayeye2006199 的观点

[blackshow]

快找

[RRRoger]

配置相关 结构相对简单 但是又可能随时添加 key 的时候把

[jtwor]

pg 对 json 解析查询不慢的，只是语法上多了一层，之前试过百万级查询也不慢。但需要做报表统计的数据还是不建议用 json ，其实存 json 是违反了三范式属性不可切割，而用 json 意味着数据是动态的，这样会使 sql 的逻辑要依赖 json 的结构(其实我觉得就是用 sql 做 nosql 的工作)。还有一个最重要的如果其他同事不会 pg 解析 json 的语法那。。这砖就只能是你一直搬了

[aristolochic]

Ruby on Rails 生态里有一个东西叫做 PaperTrail ，是一个可以为任意资源提供更改审计的库，每当对配置好的某资源进行增删改的时候都会留下记录，供以后审计和回滚。思路很简单就是挂上钩子然后把原版序列化成 JSON （也可以选增量更新的插件），存到一个多态表里面。尤其是这个多态表，什么资源都有可能，就只能用 JSON 了。如果你用的是 PostgreSQL 的话它会鼓励你使用 JSON 的字段，但是其实只是用到了 PostgreSQL 对 JSON 的校验而已。

所以，简单来说，就是快照。

[WhatIf]

1 懒
2 数据情况动态且未知，且永远在变化
3 出现了 2 ，后来稳定了，但是懒，不想改

[locoz]

面对字段很多的第三方接口返回的结果时，对非关键信息不考虑查询问题，而是为了以往万一以后需要的时候。

[Fizzyi]

我们一般把不设计查询的字段放在 json 里面

[nekoneko]

把那一部分会用作搜索条件的搞成字段不行吗.

[rodrick]

画面上就是要显示 json 的时候