像大多数事情“它取决于” . 将数据存储在列或JSON中本身并不正确或错误/好或坏 . 这取决于你以后需要做什么 . 您预测的访问此数据的方式是什么?你需要交叉引用其他数据吗?
其他人已经很好地回答了技术上的权衡 .
没有多少人讨论过您的应用和功能随着时间的推移而发展,以及这种数据存储决策如何影响您的团队 .
因为使用JSON的诱惑之一是避免迁移模式,因此如果团队没有规范,那么将另一个键/值对粘贴到JSON字段中非常容易 . 它没有迁移,没有人记得它是什么 . 没有验证 .
我的团队在postgres的传统专栏中使用了JSON,起初它是切片面包以来最好的东西 . JSON很有吸引力,也很强大,直到有一天我们才意识到这种灵活性需要付出代价,这突然成为一个真正的痛点 . 有时这一点很快就会迅速增加,然后变得很难改变,因为我们在这个设计决策之上已经 Build 了很多其他的东西 .
加班,添加新功能,使用JSON中的数据导致查看比查看传统列时可能添加的更复杂的查询 . 因此,我们开始将某些键值捕获回列中,以便我们可以进行连接并在值之间进行比较 . 馊主意 . 现在我们有重复 . 一个新的开发人员会加入并混淆?我应该挽回的 Value 是多少? JSON one还是列?
JSON字段变成了垃圾抽屉,用于这个和那个小部分 . 没有数据库级别的数据验证,文档之间没有一致性或完整性 . 这将所有责任推到了应用程序中,而不是从传统列中获取硬类型和约束检查 .
回顾过去,JSON允许我们快速迭代并获得一些东西 . 太棒了 . 然而,在我们达到某个团队规模之后,它的灵活性也使我们能够忍受长长的技术债务,从而减缓后续功能演变的进程 . 谨慎使用 .
仔细思考数据的性质是什么 . 它是您的应用程序的基础 . 如何随着时间的推移使用数据 . 它怎么可能改变?