数据库里存JSON,人家要钱你要命啊

非思我宝:
Mysql 已经原生支持json数据了，有什么问题吗？

【回复】mysql存json不好查，要用函数方法来解开数据再找数据，就没法用到索引。mongodb才是专业对口，比如存一对多关系时，用一个一维数组保存关系，这个数组还能创建索引。换mysql就得多建个中间表做索引才行
【回复】回复 @bili_5907579 :只拿来存储配置足够用了
【回复】回复 @Mikesya :按照某个专家的说法，大部分普通项目应该考虑简化架构，降低复杂度，能集成到单一关系型事务数据库里的就尽量不要再引入一套其他库。他还劝一般用户真要跟风存取向量数据就等关系型数据库加入向量数据类型。所以如果类似pg通过调大参数，做一个带索引的json字段能解决的需求，是否不应该考虑为了最大化性能和各司其职的目的而使用mongodb或es？还有一个例子，空间数据带面和线的尺寸也不小，但arcgis主要支持的存储也依然是三个关系型数据库，而不是其他带空间数据类型的nosql 数据库
罗大呦:
根据业务来的 垃圾业务就得垃圾搞法....一些配置类的东西天天改 不这样弄要命了....

【回复】回复 @山人土狗牛 :原系统没有用到这些库，总不能为个小需求单独加一个吧，你想加部门预算也不给。。。。
【回复】回复 @山人土狗牛 :调包一时爽，维护火葬场。 给征服做的项目，每两个月就要漏洞扫描，你的插件出了什么新版本了连夜打车过去现场更新。 有的东西还是选择旧的但稳定性拉满的技术最好，能跑十年不用改的那种
假梦幻泡影:
脱离具体需求谈解决方案都是扯淡。没有where查询需求时，longblob存json挺好的。有where需求时，迁移表加个索引用字段/索引表或者直接like全表搜索也能解决。当然mysql的json类型查询看上去也不错。（没试过，估计也是全表扫描）各路专家都在谈100万行应该怎么优化。实际需求不到1万行，代码怎么写简单可读怎么弄。

【回复】你做的时候问了三遍都表示没需求，后来就有了[藏狐]
【回复】你说的对。但是任何项目在立项之初都没办法预见到未来需要的扩展。任何人都不能预知未来。所以就得考虑到未来万一真的需求变化了，或者扩展了你怎么办的问题。设计时候无论甲方还是乙方都信誓旦旦说这个字段是json，绝对不会变。结果5年之后，硬是要改这个json的内容，硬是还要检索这个json，原本说好了json里内容是系统隐藏绝不会开放，但是甲方现在就是要了，你做不做吧，客户你要不要吧。确实是难办。
【回复】回复 @黑夜老猫 :赞同，需求变化是不可避免的。所以目标变成了不要简单问题弄复杂了，让可读性高，以便快速应对变化。有100万行的需求的时候，再把那一部分改成满足需求的就行了，剩下大部分依然不用动。
随便起个名就火了:
我一般用 json 存一些简单的系统设置、图册数组、第三方配置等[doge]

【回复】一些基本不会改的，要改也是手动改的，而且也不会是搜索条件，存json可以
【回复】条件生成md5当key没问题吧，kv对象库没问题
【回复】上家公司直接存一个订单对象，真的牛逼[doge]
塌一点点:
有些场景用json是真的香[吃瓜]比如，画布相关场景。你不用json，用啥呢？

【回复】@塌一点点 这种可以直接longtext，之前遇到过这种json特别大之后update特别慢，改成longtext就好了
【回复】流程引擎存数据也得存json
【回复】是不是不涉及对里面的数据做查询和索引
静水深留:
首页怎么天天推这些垃圾内容，存json 怎么了，有些用户自定义内容存成以json 格式存某个字段，查的时候还是主键查，内容原封不动给前端，前端爱咋解析咋解析，也不知道做这种视频忽悠谁

【回复】回复 @__花--海__ :什么局限，为什么不行，json 在数据库里不就是一段文本，你没见过数据库里存大文本的吗？一堆游戏的装备道具属性以json 存于数据库，我怎么没看见那些游戏因此出问题，不用json 存，难道一种属性一个字段，哪怕A物品没那个属性，但b有，就得加一个字段，这不若智吗
【回复】回复 @静水深留 :存TEXT只有一种场景。小量的不规则的不需要大量修改的静态数据，比如配置参数。 数据量大的情况下，不如存个路径引用文件，直接在文件里读写。
【回复】回复 @静水深留 :数据库本身就是序列化的存储，确实应该按字段存，存文本数据量上去性能很差。 游戏装备一般都有分类。属性可以按装备种类分表，每个表字段不同，扩展属性加字段或者新建表。 当TEXT存，哪天同一类武器某一个属性集体调整，你得所有属性都全部覆盖写入一遍。这样用数据库的就没有意义，甚至不如用自己的存.json文件，然后读写文件。
漫步风中:
Mysql支持json格式里面直接查询对应字段值了，又不用对json再次定义和转义，很麻烦吗？

朱紅輕飛濺:
我们MongoDB是这样的，什么flat，我们都是多层嵌套存的

游民4439:
数据库里面，添加预留字段存放json或是xml，用来做扩展有何不可？ 不要信口胡诌好不，抛开使用场景不谈只会愚昧的反对[吃瓜]

滋补需谨慎:
企业级应用的用户自定义字段功能 不用json还有啥做法 单体应用引入其他中间件维护成本又太高

【回复】回复 @ki_tion :给你举个例子，我以前做过一个日志系统，其中有个字段是存储日志的详情，记录的类型有几百种，如果每个类型都建一个表这没法维护吧。
【回复】回复 @shidedisda :感觉我这个项目用json可以 用户能自定义的数据格式都是固定的 存数据库里也是平面的 不会有嵌套 数据量能有个别几个表到百万都得很多年了 性能也不是问题 还可能定制各种报表 都存数据库里操作也方便
【回复】所以我们直接用mongodb，不仅字段用户要自己定义，查询统计用户都要自己组装，甚至配个表单还想自己写规则表达式[doge]
活到60安乐死:
联想项目内用的json加虚拟列，不知道是不是所有项目组都是这样，存取json的都是一套已有的封装，死难用，虚拟列依旧可以用索引，效率其实不低，只是关系型数据有泛式约定，有利于数据的维护，用了json以后如果按照非关系型数据的用法在记录里面存大量冗余，会导致数据的修改和更新变得非常麻烦。

布卡布拉:
所以要我选型，我就选pg，pg的json用得特别好

追逐幻影丶:
一条json十几m。。查询慢的一批，后面直接把json存oss上了

【回复】一条json十几m？你这json几万行啊
【回复】回复 @杂鱼_丶 : 我见过直接把图片存mysql里的
【回复】麻烦给大家看看你的10几m的json 涨涨见识
J1mmy-Z:
json可以打平了存，每个field一个column，不固定的field单独放在一个column。当然json要是变化多那就自求多福了。

达尔巴德丶法外狂秃:
pgsql对json支持就很好啊，很多企业应用自定义项用json怎么了，有问题吗

【回复】Pg 大部分场景还挺香的，甚至有人用它做消息队列跑的挺欢。没有银弹保命
【回复】回复 @ShaowKCD :严格来讲不低？君可知国产数据库，除了一个来自Oracle之外，剩下99%都是pg库的影子[doge]
【回复】pg 的json字段还支持任意键创建索引。pg太强大了
tools_people:
人家存json，就是意味着不用关心里面的数据，整存整取

葡萄树下种草莓:
只要爷高兴，直接拿TXT当nosql数据库[tv_鬼脸]

LuckyDrone:
如果业务侧没有高级查需求，都是主键整存整取，那其实无所谓。这种数据也不会大到怎样怎样，后续反而有可能对响应速度有高要求。 拆表本质上是人工干预反序列化，并且干预方式为硬编码。有得有失有适用场景的。

【回复】回复 @biliのwaiter :很常见啊，比如一些在线文档、在线绘图项目，本身数据就是以xml md json的格式在存，用户操作也是根据这个文档的主键读取或者保存，这种强行拆开一是不可能，而且也没必要
【回复】不太理解主键整存整取是在什么业务场景下