我正在考虑将 PostgreSQL 的jsonb列类型用于一个主要用作 REST-ful JSON API 的新后端项目。我相信 PostgreSQLjsonb非常适合这个项目，因为它会给我 JSON 对象，而无需在后端进行转换。
但是，我已经读到jsonb数据类型会随着键的添加而变慢，并且我的模式将需要使用主键和外键引用。
我想知道是否在自己的列中包含主键/外键（以标准的关系数据库方式），然后jsonb为其余数据设置一列会是有益的，或者这会导致问题（无论是现在还是未来） ?
简而言之，将：
table car(id int, manufacturer_id int, data jsonb)
表现好于或差于：
table car(data jsonb)
特别是在经常查找外键时？
从性能或模式的角度来看，第一个会有缺点吗？
PRIMARY KEY或FOREIGN KEY约束中涉及的所有值都必须存储为专用列（最好以规范化形式）。约束和引用不适用于嵌套在json/jsonb列中的值。
至于其余的数据：这取决于. 将它们放在jsonb（最好）值中会带来众所周知的存储非结构化文档类型数据的优点和缺点。
对于所有或大多数行都存在的属性，将它们存储为单独的列很可能会更好（更快、更清洁、更小存储）。更简单的索引和更简单的查询也是。尽管新的jsonb具有惊人的索引功能，索引专用列仍然更简单/更快。
对于很少使用或动态出现的属性，或者如果您想存储和检索 JSON 值而不需要在数据库中进行太多处理，请查看jsonb.
对于主要包含字符数据的基本EAV 结构，我会考虑没有嵌套和与 JSON 的连接hstore。还有xml（更复杂和冗长的）和json数据类型（主要被 取代jsonb），它们正在失去地位。
哪个表现更好？取决于使用情况。当您比较 SQL（关系）和 NoSQL（KeyValue 或 Document）数据库时，这是同一个问题。对于某些用例，NoSQL 数据库性能非常好，而对于其他用例则不然。
关系概念（规范化模式）针对典型的 OLTP 使用进行了优化 - 70% 读取/30% 写入、多用户、大量更新、报告计算、一些即席查询。关系概念比较广泛通用..具有非常广泛的可用性（证据，会计，处理支持，...）。通常到处都不会太糟糕。
很明显，因此专门的数据库（文档、键值、图表）在专门的用例上可以明显更好（快一个订单）。但是它们的使用范围要窄得多。当您没有优化用例时，性能可能会很差。
其他问题是数据库大小 - 记录数。生产数据库上的性能差异可能会达到数十万行。对于一些较小的数据库，影响可能不大。
Postgres 是关系数据库，我的偏好是对数据库中的所有重要数据使用规范化模式。当你用得好时，它的速度非常快。非关系类型非常适合某些模糊数据（HStore、JSON、XML、Jsonb）——它明显优于 EAV 模式（在更大的数据上表现更差）。
如果您需要做一些重要的决定，请准备原型，填写预期数据（3 年）并检查系统中一些重要查询的速度。注意：对这些基准的强烈影响使用了 hw、current load、current sw。