作为第一步，了解JOINS的价格昂贵，因此我正在考虑使用少量的整体表，而不是大量的规范化较小的表。第二点，我在使用hstore与常规表与JSONB（具有GiST索引）之间感到困惑。
AFAIK（请随时进行校正）：
通常，在Postgres中，已知hstore的性能要优于其他数据类型。 FOSDEM PGDAY的演示文稿有一些有趣的统计信息（在幻灯片的下半部分）。
https://wiki.postgresql.org/images/b/b4/Pg-as-nosql-pgday-fosdem-2013.pdf
hstore的优点是快速索引（GiN或GiST） 。但是，使用JSONB，GiN和GiST索引也可以应用于JSON数据。
来自第二象限专家的博客说：“这时可能值得在所有新应用程序中用jsonb替换hstore使用”（滚动到最后）：
http://blog.2ndquadrant.com / postgresql-anti-patterns-unnecessary-jsonhstore-dynamic-columns /
所以我想决定以下内容：
）的部分数据：应该将其放在几个
关系表中（相对较大，有很多列），还是使用hstore的多个键值存储区？
对于临时（用户提供的/非结构化的数据），应将其存储在JSON中还是将其存储在hstore中（存储在主要关系表之一中）的临时键值中？
#1 楼
关系数据库是围绕联接设计的，并进行了优化以使其良好运行。除非有充分的理由不使用规范化设计，否则请使用规范化设计。
jsonb和当您无法使用规范化的数据模型（例如，数据模型快速变化且由用户定义）时，hstore之类的内容非常有用。如果可以进行关联建模，请进行关联建模。如果不能，请考虑使用json等。如果要在json / jsonb / hstore之间进行选择，通常除非没有理由，否则通常选择jsonb。
这就是我在博客文章中所说的，仅仅解决这个话题。请阅读全文。您引用的段落指出，如果您选择动态结构，则应该选择jsonb而不是hstore，但是博客文章的其余部分说明了为什么您通常更喜欢按关系建模。
所以。相关地建模主要结构部分。如果表真的很宽，有很多列，则可能表明需要进一步规范化。不要害怕加入。学会爱加入。连接许多小表通常比查询和维护大的非规范化表快。仅当需要针对特定情况进行非规范化时，最好通过实例化视图进行规范化...但是在您知道自己需要解决实际的实际问题之前，不要这样做。
对于用户-使用jsonb贡献自由格式和非结构化数据。它的性能应该与hstore一样好，但是它更灵活，更易于使用。
需要了解的一件事：像在jsonb上使用的GiST和GIN索引通常比普通b效率低得多。 -树索引。它们更灵活，但是普通列上的b树索引几乎总是快得多。
评论
非常感谢Craig，现在我有了更好的理解，知道该怎么做。后续问题：如果我以两列格式存储喜欢或关注者（postsid和user_id，代表喜欢），使用具有两列的关系表还是使用hstore更好？ （我不介意将其变成一个新问题）
–优格
2015年9月23日在10:05
@Yogesch听起来像是沼泽标准的m：n连接表，格式一致且稳定。问题应该始终是“是否有充分的理由我不应该针对这种特殊情况采用通常的关系方式？”。
–克雷格·林格（Craig Ringer）
2015年9月23日10:30在
hstore已过时。使用jsonb。
–danger89
16年5月4日在12:40
@ danger89实际上，它没有被正式弃用，尽管我认为不再有任何理由使用它来支持jsonb了。在任何情况下……这都是要点。问题在于是否要进行关系建模还是使用结构化数据类型。
–克雷格·林格（Craig Ringer）
16年5月4日在15:15
评论
加入并不昂贵。谁对你说的由于关系数据库的整个概念基本上都围绕联接（从实际角度出发），因此这些产品非常擅长联接。正常的思维方式是从正确规范化的结构开始，然后在性能真正需要阅读方面的时候进入奇特的规范化和类似的工作。 JSON（B）和hstore（和EAV）非常适合结构未知的数据。@Yogesch这些链接包含一些有趣且矛盾重重的内容:)从道德上讲，MySQL似乎在联接方面很（很），并且NoSQL人们倾向于在没有任何实际事实依据的情况下概括这个概念。另一方面，Aaron和Max对那个p字很敏感-它的广泛用法说明了非母语的人（包括我自己）如何愉快地使用错误的字。
@Yogesch实际上，我敢肯定，互联网上有一个来源可以“证明”任何东西，就像任何宗教文字都可以用来为暴行辩护一样（在整个历史过程中都可以看到）。的确，您所做的工作越少，成本就越少，但是总会有一些折衷。
@Yogesch：对于需要大量了解数据访问模式的读取繁重的操作，避免联接很重要，因此可以安全地将所需的所有数据放入一行。但是，这会使其他联接的成本更高。谁说您不需要以许多不同的方式合并数据来回答各种问题？现在，我们将简单地介绍到关系数据建模的理论...
@Yogesch在我的实践中，数据库的瓶颈很少是RAM或CPU，而是I / O-这样避免存储冗余数据的方法仍然很重要。正如克里斯所说，如果您始终只能以一种方式查看数据，那么这可能是值得的。如果没有，那么您那里会有大量且高度灵活的数据。