这是一个创建于 2264 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天开发老大说让我，学习一下 mysql 的 json 字段怎么用。说我使用的路子太野。。。
鉴于此我看一下我写的代码，感觉没什么毛病。generator 生成的 DO 中对应 json 字段类型是 Object 该 DO 字段展示为: Object data
我在与前台交互时发现传到前台是未在预期之内的类型多了一对双引号在外面，""url1,url2""
于是我在后台使用 JSON 包转换了一下,代码如下格式。 Object.setData(null == Object.getData() ? "" : JSON.parse(Object.getData().toString()));
请问这样路子非常野路子么？
补充，这个表之前是建好的包括 DO，我就是查询给前台交互展示的。
 | 1 www6688w 2019-09-25 11:06:44 +08:00  1 json 字符串 我目前都是用 vachar 来存，虽然 MYSQL 提供了这个 json 类型，不过目前还没使用过。 一般存储为 json 的都是不重要的附带信息，而且也不会用作查询 |
 | 2 MrTangKe OP @www6688w 是这样的，附带信息里面存储的扩展字段。我查询也不用这个扩展字段去查询，只是通过主键查询后，要返回这个扩展信息给前台，约定的是字符串类型，如果不转回 JSON 格式返回会多一个 "" 前台解析就报错，所以我后台使用 Json.parse （）一下，然后就被说路子很狂野。我就不明所以了。。。 |
| 3 www6688w 2019-09-25 11:15:20 +08:00 @MrTangKe emmm，我觉得逻辑上没有问题，而且我自己也这样写过 倘若 Mysql 还没有发布 json 类型之前，，那这样写不也是很正常的 可能他们是觉得这样写太粗暴了一点，且 json 的解析也会有消耗 |
 | 4 DsuineGP 2019-09-25 14:44:22 +08:00 1 虽然没看懂你在说啥,但是 JSON_UNQUOTE 了解一下准没错 |
 | 5 kanepan19 2019-09-25 15:42:34 +08:00 1 你怼他，淘宝 item 表 feature 字段也是 json，路子很野？ |
 | 6 xuanbg 2019-09-25 16:03:30 +08:00 1 查询的时候是这样的：select column ->> '$.field' from table; myBatis 直接映射成对象要用这个注解：@Results({@Result(property = "column", column = "column", javaType = XxxDto.class, typeHandler = JsonTypeHandler.class)}) |
| 7 MrTangKe OP @xuanbg 谢了已经解决了。旧的查询方法和 mapperXml 文件已经建立使用很久了。我又根据 4 楼的建议吧 SQL 优化了。话说这也不是我路子野，基础服务方法就比较野。。。 |
 | 8 hantsy 2019-09-25 16:08:33 +08:00 json 如果记得没错的话在 Pg 里面早就有了，可以自己写 Hibernate 扩展去支持，Github 上有现成的。 |
| 9 xuanbg 2019-09-25 16:10:27 +08:00 JSON 类型非常非常非常好用！！！以前需要几十个字段存储的 xx 信息什么的，现在一个字段搞定。特别是一对多的那种，以前是要搞一个明细表存储的，读取多条记录的时候还是挺恶心的。现在也是一个字段直出，不需要联表，也不需要迭代分组处理了。 当然，滥用 JSON 类型，也是会造成很大的麻烦的。 |
 | 10 lolizeppelin 2019-09-25 16:40:55 +08:00 mysql 具体不太清楚 pg 里 on 和 where 在逻辑优化部分处理后 最终落地都是 “条件”形式 或 “过滤”形式查询数据 条件就是可以走索引的,过滤的就是全查然后过滤（走索引并不一定比全表查块！！） 通过预估数据需要处理的量,并通过这个量和顺序读取和随机读取的消耗比做计算后选择是否走索引 如果逻辑优化后让,分析器错误认为需要查询的数据量较大导致走过滤,性能就差,否则没区别 |
| 11 lolizeppelin 2019-09-25 16:41:25 +08:00 发错位置了 orz |
Select Language