这是一个创建于 2839 天前的主题，其中的信息可能已经有所发展或是发生改变。
把零碎的业务数据都存在一个 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 缓存一样的原则。 |
 |
4
kindjeff 2017-02-16 23:59:52 +08:00 via iPhone
|
 |
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