Yog*_*sch 32 postgresql database-design
我试图决定数据库设计，在这个阶段尽可能少的假设（关于 web 应用程序的实际发展）。
作为第一步，了解 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/
所以我想决定以下几点：
Cra*_*ger 48
关系数据库是围绕连接设计的，并经过优化以很好地完成它们。
除非您有充分的理由不使用标准化设计，否则请使用标准化设计。
jsonb事情就是这样hstore的，因为当你好的不能用标准化的数据模型，比如当数据模型迅速改变，并且是用户定义的。
如果您可以对其进行关系建模，请对其进行关系建模。如果你不能，考虑 json 等。如果你在 json/jsonb/hstore 之间进行选择，一般选择 jsonb，除非你有理由不这样做。
这就是我在我的博客文章中所说的，它只是针对这个主题。请阅读整篇文章。您引用的段落指出，如果您选择动态结构，您应该选择 jsonb 而不是 hstore，但博客文章的其余部分是关于为什么如果可以的话，您通常应该更喜欢关系建模。
所以。对主要结构部件进行相关建模。如果表格真的很宽，有很多列，这可能表明需要进一步规范化。不要害怕加入。学会爱加入。连接许多小表通常比查询和维护大的非规范化表要快。仅在您需要针对特定情况进行非规范化时，最好通过物化视图……但在您知道需要并有实际的具体问题需要解决之前不要这样做。
对于自由格式和非结构化的用户贡献数据，请使用 jsonb。它的性能应该与 hstore 一样好，但它更灵活且更易于使用。
一个相关的事情就明白了：像那些依据和GIN索引上jsonb使用一般多比一个普通的B树索引效率较低。它们更灵活，但普通列上的 b 树索引几乎总是要快得多。