带有索引的JSONB与hstore

在此阶段，我试图以尽可能少的假设（关于Web应用程序实际如何演变）来决定数据库设计。

第一步，了解JOINS昂贵，因此我考虑使用少量的整体表，而不是大量的规范化较小表。第二点，我对使用hstore与常规表与JSONB（具有GiST索引）之间感到困惑。

AFAIK（请随时纠正）：

1. 通常，在Postgres中，已知hstore的性能要优于其他数据类型。FOSDEM PGDAY的演示文稿有一些有趣的统计数据（在幻灯片的下半部分）。 https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf

2. hstore的一个优点是快速索引（GiN或GiST）。但是，使用JSONB，GiN和GiST索引也可以应用于JSON数据。

3. 来自第二象限专家的博客说：“这时可能值得在所有新应用程序中用jsonb替换hstore使用”（滚动到最后）：http ://blog.2ndquadrant.com/postgresql-anti-patterns-unnecessary -jsonhstore-dynamic-columns /

因此，我想决定以下几点：

1. 对于数据的主要（结构化）部分：它应该放在几个关系表中（相对较大，有很多列），还是应该是使用hstore的许多键值存储？
2. 对于临时（用户提供的/非结构化的）数据，应该将其存储在JSON中还是将其存储在hstore中（存储在主要关系表之一中）？

关系数据库是围绕联接设计的，并进行了优化以使其良好。

除非有充分的理由不使用规范化设计，否则请使用规范化设计。

jsonb事情就是这样hstore的，因为当你好的不能用标准化的数据模型，比如当数据模型迅速改变，并且是用户定义的。

如果可以建立关系模型，则可以建立关系模型。如果不能，请考虑使用json等。如果要在json / jsonb / hstore之间进行选择，则通常选择jsonb，除非您有理由不这样做。

这就是我在博客文章中所说的，该文章仅涉及此主题。请阅读全文。您引用的段落指出，如果您选择动态结构，则应该选择jsonb而不是hstore，但是博客文章的其余部分是关于为什么通常应该尽可能地进行关系建模的原因。

所以。相关地建模主要结构部分。如果表确实很宽，有很多列，则可能表明需要进一步规范化。不要害怕加入。学会爱加入。连接许多小表通常比查询和维护大的非规范化表快。仅当需要针对特定​​情况进行非规范化时，最好通过实例化视图进行非规范化……但是直到您知道自己需要解决实际的实际问题才可以进行非规范化。

对于自由格式和非结构化的用户贡献数据，请使用jsonb。它的性能应该与hstore一样好，但是它更加灵活且易于使用。

一个相关的事情就明白了：像那些依据和GIN索引上jsonb使用一般多比一个普通的B树索引效率较低。它们更灵活，但是普通列上的b树索引几乎总是快得多。