这是一个创建于 3213 天前的主题，其中的信息可能已经有所发展或是发生改变。
把零碎的业务数据都存在一个 JSON 列中，读写的时候还得解析一下，觉得怪怪的。可在 MySQL5.7 版本中，已经官方支持了 JSON 数据类型......
该怎么看待这种做法？
 | 1 fityme 2017-02-16 23:44:30 +08:00 有什么好纠结的。只要有可能，尽量不要存 json ，没办法的情况下存了也就存了。 老想着 json 支持的话，为嘛不直接去用 MongoDB 之类的文档数据库 |
 | 2 Tuisku 2017-02-16 23:45:11 +08:00 via Android 存 JSON 算啥，我司前辈 SQL Server 里存 XML ，这倒没啥， SQL Server 也有 XML 类型。然后他在 XML 里面又存了 JSON |
 | 3 hardway 2017-02-16 23:48:04 +08:00 我觉得只要是不常用的杂碎数据放在 json 没什么不可以 ，节省开发时间，如果某个 field 以后使用频度提高了可以再提升到数据库字段，频度再高提高到 memcache 或者 redis ，很健康。 数据分级，就和硬盘 > 内存 > CPU 缓存一样的原则。 |
 | 6 czheo 2017-02-17 00:13:27 +08:00 支持类 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 操作性能提升。（当然这和具体实现方式有很大关系） |
 | 7 shoaly 2017-02-17 08:49:08 +08:00 用不用 json 的 判断点在于 这一个字段 是否需要 检索, where, 连表, 或者排序 |
 | 8 0915240 2017-02-17 10:51:42 +08:00 如果只是存储，少涉及关联查询。数据结构很多很乱的话 还是可以用 JSON |
 | 9 fantastM OP @shoaly 设计新表的时候，会尽量向范式靠拢，有时为了查询效率会冗余字段......用到 JSON 列，估计是被产品后需的需求弄烦了，才索性破罐子破摔的>_> |
 | 10 jarlyyn 2017-03-02 17:27:39 +08:00 不够。 还需要一列存 schema |
Select Language