在数据库中，用多余的一列存储 JSON 数据

[fantastM]

把零碎的业务数据都存在一个 JSON 列中，读写的时候还得解析一下，觉得怪怪的。可在 MySQL5.7 版本中，已经官方支持了 JSON 数据类型......

该怎么看待这种做法？

[fityme]

有什么好纠结的。只要有可能，尽量不要存 json ，没办法的情况下存了也就存了。
老想着 json 支持的话，为嘛不直接去用 MongoDB 之类的文档数据库

[Tuisku]

存 JSON 算啥，我司前辈 SQL Server 里存 XML ，这倒没啥， SQL Server 也有 XML 类型。然后他在 XML 里面又存了 JSON 🙈

[hardway]

我觉得只要是不常用的杂碎数据放在 json 没什么不可以 ，节省开发时间，如果某个 field 以后使用频度提高了可以再提升到数据库字段，频度再高提高到 memcache 或者 redis ，很健康。

数据分级，就和硬盘 > 内存 > CPU 缓存一样的原则。

[kindjeff]

https://www.v2ex.com/t/288760

[fantastM]

@hardway 谢谢，很受用。

[czheo]

支持类 JSON data type 是一种潮流， pg 和 MySQL 都支持了。
Google 最近出的 Spanner 也支持类似的数据类型（ Protocol Buffer ）。
这种类型至少有以下优势：
1 、更灵活的 schema 。普通 table 每次修改 schema 都需要 table lock ，用 JSON 可以提高系统可用性。
2 、需要更少的 table 和 column 。以后管理、 sharding 的时候更容易。
3 、业务端不需要 table 和 object 的 mapping ，直接解析就可以用。
4 、 Spanner 论文里还指出了，由于更容易分布式执行，由此带来的 join 操作性能提升。（当然这和具体实现方式有很大关系）

[shoaly]

用不用 json 的 判断点在于 这一个字段 是否需要 检索, where, 连表, 或者排序

[0915240]

如果只是存储，少涉及关联查询。数据结构很多很乱的话 还是可以用 JSON

[fantastM]

@shoaly 设计新表的时候，会尽量向范式靠拢，有时为了查询效率会冗余字段......用到 JSON 列，估计是被产品后需的需求弄烦了，才索性破罐子破摔的>_>

[jarlyyn]

不够。

还需要一列存 schema