而它也可以匹配更复杂的情况，下面这个例子也是 true：
下面这个例子可能新用户会有点儿迷惑，但是其实也很好的契合了这个规则：
但是应该注意的是，下面这个例子结果是 false：
这也不难理解，{} 和 [] 不相等。
下面这个例子比较有意思：
这里要注意的是，比较一个 JSON 数组是否匹配另一个时，它并不要求两个数组的顺序相等，只要右边是左边的真子集就可以：
这个规则契合了PostgreSQL的倒排索引，PostgreSQL的gin索引，JSONB 字段类型和匹配操作 @> 成为了一个非常有力的组合。在过去几年里，我习惯为一些重要的业务表加上一个类型为 JSONB 的meta 字段，并对其建立 gin 索引
需要注意的是指定索引类型时的 create index 语法。
这样的设计可以解决很多传统上难以解决的问题，例如我可以给每个条目打上一个 tag 列表，取带有某几个 tag 的条目就是一个简单的匹配查询：
因为有gin索引的帮助，这个搜索的性能足够常规的互联网应用所需。
甚至我的在 CSDN NLP 组的同事还挖掘出了新的用法。我们在一个存储树节点的表里，保存了一个 meta 字段，其中有一个 path 列表，存储当前字段在树中的路径，它的每一项都是 {"id": node_id, "title": something}这样的结构，而我们搜索某一个节点下面的所有子节点，包括其隔代的子节点时，仅需要执行这样一个查询：
当然这个匹配操作也有它的限制，它在右边是左边的真子图的情况下才会匹配成功。例如我希望查找 tags 列表中包含我搜索项中的任何一个（即两者存在非空交集）的情况，用这种方法就不行了。此时我们需要另一个运算符 ?|
注意这几个例子，首先右边的运算符不再是jsonb，而必须是 text[]，其次它其实是检查 key 值——也就是可以通过 gin 索引存储的值：
PostgreSQL 支持 JSON 和 JSONB 已经有十余年，每一个版本都在积极的增强其 JSON 数据处理能力，即使我近十年来的积极探索和学习，也没有全面的了解。这个交集运算也是近期在 NLP 组的工作过程中才注意到的。
到此这篇关于PostgreSQL JSONB的匹配和交集的文章就介绍到这了,更多相关PostgreSQL JSONB内容请搜索七叶笔记以前的文章或继续浏览下面的相关文章希望大家以后多多支持七叶笔记！
