在关系型数据库中频繁使用 JSON 格式来存储不需要索引的数据好么？

Question

最近在设计一些复杂的 MySQL 数据库表。
碰到一些需要存储用户所得成就、用户所得称号、用户消息之类的数据的需求。

感觉这类数据其实可以直接用 JSON 格式存储在 user_meta 表的 text 类型字段里。
而不需要设计过于复杂的表。
当然并不是所有数据都存储在一起，可能按照 100 条数据/条记录的方法。

优点是：

• 每页显示 50 条用户数据的话，每页只要读一次数据库的一条记录就行了，而不需要遍历 50 条记录。
• 把数据库的压力分担到程序执行上，貌似更多情况是数据库压力过大导致网站挂掉。
• 不需要设计复杂的数据库表，因为这类数据的结构可能经常变动，用 JSON 可以在程序中做好处理。

但是我不知道这样设计的缺点，因为我没有足够的经验。
所以我的问题是：
在关系型数据库中频繁使用 JSON 格式来存储不需要索引的数据好么？
或者有没有更好的方案呢？

麻烦大家了，谢谢 =w=

Answer 1

既然不需要索引，这种情况看起来用KeyValue库更合适一些，比如TC/TT, Bdb, Redis；或者MongoDb这种文档型数据库也可以（但也有很多设计上的坑）。

其他理由如下：
1. Mysql库里慎用text字段，性能不乐观……
2. 一旦需要对这些数据进行索引或者统计，从MySQL中解出所有的数据并重新入库成本相当巨大……
3. 大JSON的parse性能同样不乐观，而且对于中文数据，纯JSON太占空间了……
4. 100条/记录的存储方式，如果需要对其中一条进行增加/删除/更新，即需要更新整个100条，更新量比较大；同样可能会产生并发问题，需要自行实现行锁。

一般情况下，如果你用了关系数据库，不要轻易（为了性能/空间）做违反范式的设计，除非你有足够的理由和把握，否则会给未来的维护升级带来无尽的麻烦。

通常建议：
1. 换Key-Value库/文档库(mangodb)
2. 或者关系库做好缓存和索引优化，可以把一个用户相关的勋章称号都缓存在一个key下，这个是经过被各大网站验证过无数遍的设计……

Answer 2

数据库 = PAYLOAD + INDEX
以上不是公理, 却是更好的了解数据库的一个新视角

提问者的数据库设计方案, 有点类似大神Bret Taylor(FB ex-CTO)的一篇blog
http://backchannel.org/blog/friendfee...
相信这种解决方法已经在frendfeed被验证过, 经得起考验

KV的编程的一条核心思想, 就是把那些需要query的东西, 变成已经存在的数据.
比如用户发的所有帖子, 以前需要按照user_id查询, 现在我们把帖子id放到users表的json里面, 那么一句查询(依赖索引)就变成了n条k/v的get操作.(请灵活运用)

我自己也根据这个博客写过一些实现 https://github.com/kernel1983/NoMagic 并已经在生产环境使用了.

我的个人建议, 无需一开始就使用key/value数据库, 但是将mysql设计的可以轻易的用kv数据库代替, 以提高数据库PAYLOAD部分的吞吐能力. 而在INDEX部分, B Tree算法没有过时, mysql就不会过时.

对于mongodb的复杂算法和实现, 我更加倾向于memcachedb/redis这种一句话就可以讲清楚自己在做什么的数据库方案.

总之, 解决问题的思想无需被范式捆绑.
多看一看别人怎么做的, 你的奇思妙想可能已经不是独一无二的了.

Answer 3

目前能想到的问题有两个：
1、无法对这些数据进行排序

2、搜索好像不是很方便？

Answer 4

感觉若是要对json操作的话挺耗费性能的吧

Answer 5

虽然这个问题过去了很久，但在我现在的工作中仍然时不时会遇到这样的问题。
发现个比较有参考价值的问答：Storing JSON in database vs. having a new column for each key