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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

• 请不要在回答技术问题时复制粘贴 AI 生成的内容

这是一个创建于 1157 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

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

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

存 json 实用性受限呐。

JSON

联表

表字段

字段

53 条回复 • 2021-10-29 10:13:08 +08:00

xiang0818

2021-10-27 15:04:16 +08:00

不考虑

binux

2021-10-27 15:07:33 +08:00 via Android

当然是不需要「做查询条件，联表条件，分组条件」的时候啊

pengtdyd

2021-10-27 15:13:22 +08:00

设计这个极度依赖经验，看具体业务而定

leeg810312

2021-10-27 15:21:29 +08:00

我有在字段里存 json 数据，但仅限单表查询，不会用 json 里的数据联表、分组、排序。查询中需要处理 json 时，用 EF Core DbFunction 写一个方法注册到 DbContext 里，一般用在 Linq Where 或 Select 方法里。

bleaker

2021-10-27 15:31:17 +08:00

非常确定（在自己跑路之前）不会和其他东西做关联查询，并且 json 字段内容非常不固定的时候

非要查的话可以用 JsonPath （ linq 更好用但是非 dot net 没得）糊一下

Visitor233

2021-10-27 15:34:25 +08:00

@leeg810312 我刚才也看到了 DbFunction ，确实有意思，可惜 Microsoft.EntityFrameworkCore v5.0.0 包里的方法没有适合操作 json 的，json_value 也只是 sql server 中用。

itechnology

2021-10-27 15:40:28 +08:00

在记录第三方接口调用结果的时候。

cco

2021-10-27 15:43:01 +08:00

存复杂结构的时候。

Seayon

2021-10-27 15:46:52 +08:00

输入输出参数的原始日志

InDom

2021-10-27 15:47:08 +08:00

如果不确定的话，干脆上 MongoDB 吧，用的时候也省心了。

tabris17

2021-10-27 15:48:20 +08:00

在确定了产品经理有多不靠谱的情况下

tabris17

2021-10-27 15:49:18 +08:00

两个前提：
1 、结构不确定
2 、数据整存整取

Visitor233

2021-10-27 15:54:17 +08:00

@bleaker JsonPath 看了会，好像可以用上，谢谢！

wlfeng

2021-10-27 16:03:53 +08:00

举个例子，支付系统，不同平台的配置参数

MonikaCeng

2021-10-27 16:06:29 +08:00 via Android

真要存 json 我就 mongo 了

MonkeyJon

2021-10-27 16:12:22 +08:00

再不想多加字段或者满足不了业务的情况下

Chad0000

2021-10-27 16:26:59 +08:00

再举个例子：快递面单打印模板，这完全是动态化的数据，也不会用来做查询。我就用 JSON 保存。同时支付系统参数我也是这么保存的。

labulaka521

2021-10-27 16:32:08 +08:00

一些属性信息，不会被 sql 查询的

chengyiqun

2021-10-27 17:17:44 +08:00

记录第三方接口调用结果的时候

RainCats

2021-10-27 17:21:48 +08:00

一些因为业务显示加的乱七八糟的东西，并且不作查询条件字段的时候

qwerthhusn

2021-10-27 17:23:52 +08:00

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

RangerWolf

2021-10-27 17:24:19 +08:00

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

clockwork1122

2021-10-27 17:25:06 +08:00

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

Biggoldfish

2021-10-27 17:28:52 +08:00 via Android

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

BeautifulSoap

2021-10-27 17:29:25 +08:00

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

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

infun

2021-10-27 17:30:59 +08:00

存快照信息用，其它极少

shylockhg

2021-10-27 17:36:16 +08:00

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

sunrain

2021-10-27 17:44:24 +08:00

自定义埋点

tranfer

2021-10-27 18:10:15 +08:00

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

timethinker

2021-10-27 18:15:35 +08:00

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

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

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

4771314

2021-10-27 18:16:46 +08:00

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

fxxkgw

2021-10-27 18:54:11 +08:00

只存储，不涉及查询

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

2i2Re2PLMaDnghL

2021-10-27 19:02:14 +08:00

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

meiyoumingzi6

2021-10-27 19:09:40 +08:00

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

unclemcz

2021-10-27 19:13:13 +08:00

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

Visitor233

2021-10-27 19:21:12 +08:00

@clockwork1122 你这结构有点意思哦

Visitor233

2021-10-27 19:21:38 +08:00

@qwe520liao 长见识了，谢谢！

CoderLife

2021-10-27 19:40:01 +08:00

snapshot 这种得存 json

loading

2021-10-27 20:56:19 +08:00

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

jorneyr

2021-10-27 21:23:56 +08:00

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

wxw752

2021-10-28 01:08:20 +08:00

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

dayeye2006199

2021-10-28 06:44:27 +08:00

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

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

qdcanyun

2021-10-28 09:55:51 +08:00

赞同 @binux 的观点

nziu

2021-10-28 10:04:49 +08:00

赞同 @dayeye2006199 的观点

blackshow

2021-10-28 10:41:22 +08:00

快找

RRRoger

2021-10-28 10:46:00 +08:00

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

jtwor

2021-10-28 10:59:32 +08:00

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

aristolochic

2021-10-28 11:57:07 +08:00

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

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