网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。
一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!
| — | — | — |
| JSON类型 | PG数据类型 | 说明 |
| String | text | 不允许\u0000
,如果数据库编码不是 UTF8,非 ASCII Unicode 转义也是这样 |
| Number | Number | 不允许NaN
和 infinity
值 |
| Boolean | boolean | 只接受小写true
和false
拼写 |
| NULL | 无 | SQL NULL
是一个不同的概念 |
这里关于编码有一个需要解释的地方,就是Unicode的转义问题。这里涉及到数据库在创建的时候是不是使用utf-8的编码存储。在json类型的输入函数中,不管数据库 编码如何都允许 Unicode 转义,并且只检查语法正确性(即,跟在\u 后面的四个十六进制位)。但是,jsonb的输入函数更加严格:它不允 许非 ASCII 字符的 Unicode 转义(高于U+007F的那些),除非数据 库编码是 UTF8。jsonb类型也拒绝\u0000(因为 PostgreSQL的text类型无法表示 它),并且它坚持使用 Unicode 代理对来标记位于 Unicode 基本多语言平面之外 的字符是正确的。合法的 Unicode 转义会被转换成等价的 ASCII 或 UTF8 字符进 行存储,这包括把代理对折叠成一个单一字符。在把文本 JSON 输入转换成jsonb时,RFC 7159描述 的基本类型会被有效地映射到原生的 PostgreSQL类型(如 上表描述)。因此,在合法 jsonb数据的组成上有一些次要额外约束,它们不适合 json类型和抽象意义上的 JSON,这些约束对应于有关哪些东西不 能被底层数据类型表示的限制。尤其是,jsonb将拒绝位于 PostgreSQL numeric数据类型范 围之外的数字,而json则不会。不过,实际上这类问题更可能发生在其他实 现中,因为把 JSON 的number基本类型表示为 IEEE 754 双精度浮点 是很常见的(这也是RFC 7159 明确期待和允许的)。当在这类系 统间使用 JSON 作为一种交换格式时,应该考虑丢失数字精度的风险。
二、PG中json的简单操作
1、基础json数据操作
-- 简单标量/基本值
-- 基本值可以是数字、带引号的字符串、true、false或者null
SELECT '5'::json;
-- 有零个或者更多元素的数组(元素不需要为同一类型)
SELECT '[1, 2, "foo", null]'::json;
-- 包含键值对的对象
-- 注意对象键必须总是带引号的字符串
SELECT '{"name": "张三", "age": 39, "active": false,"sex":"男"}'::json;
-- 数组和对象可以被任意嵌套
SELECT '{"foo": [true, "bar"], "tags": {"a": 1, "b": null}}'::json;
2、json和jsonb输出对比
SELECT '{"bar": "baz", "balance": 7.77, "active":false}'::json;
json
-------------------------------------------------
{"bar": "baz", "balance": 7.77, "active":false}
(1 row)
SELECT '{"bar": "baz", "balance": 7.77, "active":false}'::jsonb;
jsonb
--------------------------------------------------
{"bar": "baz", "active": false, "balance": 7.77}
(1 row)
通过这里输出可以看到,将目标对象作为json输出时,输出结果和输入基本保持一致。 对于第二条语句而言,内容上似乎没有什么太大的变化,但是输出结果的顺序与第一条有明显的区别。
再来看一组有意思的输出,依然是关于jsonb和json的number结果的展示。
SELECT '{"reading": 1.230e-5}'::json, '{"reading": 1.230e-5}'::jsonb;
json | jsonb
-----------------------+-------------------------
{"reading": 1.230e-5} | {"reading": 0.00001230}
(1 row)
很明显的区别是jsonb被数据库的执行引擎给优化了,展示结果与json也不同。
3、jsonb包含测试
在很多的场景中,我们会使用API对两个json进行是否包含的判断,因为在json类型中,使用包含判断也是比较耗费时间的,在pg数据库中,天然提供了数据库层的包含函数,以此来提高查询匹配能力。在jsonb的查询中,使用@>进行包含的查询操作。
-- 右边具有一个单一键值对的对象被包含在左边的对象中:
SELECT '{"product": "PostgreSQL", "version": 9.4, "jsonb": true}'::jsonb @> '{"version": 9.4}'::jsonb;
-- 右边的数组不会被认为包含在左边的数组中,
-- 即使其中嵌入了一个相似的数组:
SELECT '[1, 2, [1, 3]]'::jsonb @> '[1, 3]'::jsonb; -- 得到假
-- 但是如果同样也有嵌套,包含就成立:
SELECT '[1, 2, [1, 3]]'::jsonb @> '[[1, 3]]'::jsonb;
-- 类似的,这个例子也不会被认为是包含:
SELECT '{"foo": {"bar": "baz"}}'::jsonb @> '{"bar": "baz"}'::jsonb; -- 得到假
![img](https://img-blog.csdnimg.cn/img_convert/96a22da854c9fd67ac090abbdfbfc812.png)
![img](https://img-blog.csdnimg.cn/img_convert/081546a30875324e56e06fd893d521e9.png)
![img](https://img-blog.csdnimg.cn/img_convert/bffde9d17c9ab67cb09a64a13cee4c8f.png)
**既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,涵盖了95%以上大数据知识点,真正体系化!**
**由于文件比较多,这里只是将部分目录截图出来,全套包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新**
**[需要这份系统化资料的朋友,可以戳这里获取](https://bbs.csdn.net/topics/618545628)**
包含大厂面经、学习笔记、源码讲义、实战项目、大纲路线、讲解视频,并且后续会持续更新**
**[需要这份系统化资料的朋友,可以戳这里获取](https://bbs.csdn.net/topics/618545628)**