你们会在数据库字段里存 json 字符串吗

[zx9481]

当前项目中存在一个包含 7-8 个级联下拉框的查询模块，其中多数控件具有 3-4 级嵌套关系。考虑将所有枚举数据通过 AI 预处理生成结构化 JSON ，采用单字段存储方案，配合 Redis 持久化缓存，最终直接向前端输出完整数据结构。

大佬们，这种设计是否具备可行性？这种"全家桶"式的处理方式会不会有什么坑？

[nxforce]

我也遇到过这种深嵌套的结构，连表能拖死 MySQL ，最后把这部分数据单独扔 mongodb 完事了。

[vincentWdp]

要不要查询, 以及如何查询决定了如何存储.

[lixikei]

我就把数据 json 字符串存了一个字段

[hkiJava]

有这种设计方案的,就是修改字段值不大方便,如果读的频率大于写,可以搞

[edward1987]

看数量级吧，如果一次性返回数据量很大的话，还是分层级缓存好点。

[635925926]

级联应该就是查出来（ pid ，level ），后端组合成 tree 。

[lcbp]

这类数据直接放到 MongoDB 里面

[niubiman]

我们项目有一些字段就是直接 json 存的, 比如我们有一个场景是订单明细需要多次入库, 这个就是在订单明细上直接用 json 保存入库记录, 单开一张表的话感觉有点脱裤子放屁的感觉, 对了我们用的库是 pg, 目前没有性能上的问题

[liKeYunKeji]

存过数组['你好','我好','大家好']

[niubiman]

@hkiJava 对的, 偏日志类的, 并且层级不太深的直接 json 更合理, 在 DDD 中也推荐在一些场景直接使用 json 而不是开表

[kneo]

如果数据库支持原生 Json 字段就存。不支持的话再考虑考虑。

[moefishtang]

用 json 存过订单详情（订购的商品条目之类的），因为不想另外起一个表，觉得关联查询麻烦

[laikicka]

postgresql 没问题

[NessajCN]

mongodb 了解一下

[neptuno]

都是些枚举值，而且还有 redis 缓存，怕啥，直接上

[superchijinpeng]

大量字段全是 JSON ，JSON 中还有大量 Base64

[yhnbgfd]

没问题, 就是一个{}或者[]的字符串而已.

[rlds]

大量的 json 丢 mongodb 去了。

[sazima]

属于常规操作

[zoharSoul]

存就行了 跟 ai 啥关系

[LASockpuppet]

级联的一般会扁平化吧

[jqtmviyu]

见过表单转 json 存 mysql, 然后用在回填上的. 仔细想想, 也没什么其他方法呀.

[KKKKKKKKKKKKKKKK]

pgsql 没问题，把需要查询的字段拿出来就好了

[lyxxxh2]

以前存,后面统计/修改 火葬场,后悔死我了。

[spritecn]

不稳定不索引的和主业务关系不大的数据会存,并且字段名大概率叫 extJson

[tenserG]

存了 但是数据量不大

[spritecn]

@lyxxxh2 哈哈哈,只有一个模块这么干过,主数据一个 json,附加数据一个 json,跑倒时没有问题,统计数据那叫一个痛苦,虽然 mysql5.7+的 json 查询还算是比较成熟的,但每次查询都需要复习一下 mysql 的 json 箭头语法

[Hudiebbk]

这个要看查询的需求,如果查询需求简单没有过多嵌套,当然可以搞,我现在设计很多字段直接 json 存储,而且 mysql8 对 json 支持也还可以,可以建索引如有必要

[volvo007]

我用 pg ，丝滑~

[PatchouliTC]

原则上可以,毕竟业务上经常遇到这类单独拉字段用不上/单独拉表关系没用的数据,但是指不定以后业务升级会用到的一堆玩意,基本就是归档一个 json 然后找个字段塞进去美其名曰 snapshotData,只要你确定你没有后端复杂查询过滤部分会涉及到 js 内层级结构就随便搞[如果业务逻辑要求是先获取单条记录再对 js 内数据判断也可以这么玩]

[zjstar]

还是看业务，我们这边一般这种，查远远高于改，那么就是可以吧 json 存一个字段的