当前项目中存在一个包含 7-8 个级联下拉框的查询模块，其中多数控件具有 3-4 级嵌套关系。考虑将所有枚举数据通过 AI 预处理生成结构化 JSON ，采用单字段存储方案，配合 Redis 持久化缓存，最终直接向前端输出完整数据结构。
大佬们，这种设计是否具备可行性？这种"全家桶"式的处理方式会不会有什么坑？

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

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

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

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

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

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

这类数据直接放到 MongoDB 里面

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

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

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

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

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

postgresql 没问题

mongodb 了解一下

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

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

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

大量的 json 丢 mongodb 去了。

属于常规操作

存就行了 跟 ai 啥关系

级联的一般会扁平化吧

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