作为第一步,理解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的一些键值存储？
>对于ad hoc(用户贡献/非结构化)数据,它应该位于hstore中的JSON还是ad hoc键值存储中(键存储在其中一个主关系表中)？
除非您有充分的理由不使用标准化设计,否则请使用标准化设计.
当你不能使用规范化的数据模型时,例如当数据模型快速变化并且是用户定义时,jsonb和hstore之类的东西是很好的.
如果您可以对其进行关系建模,请对其进行关联建模.如果你不能,请考虑json等.如果你在json / jsonb / hstore之间进行选择,一般选择jsonb,除非你有理由不这样做.
这就是我在my blog post中所说的,它只涉及这个主题.请阅读整篇文章.您引用的段落指出,如果您选择动态结构,则应选择jsonb而不是hstore,但博客文章的其余部分是关于为什么您通常应该更喜欢关联模型(如果可以).
所以.关联地对主要结构化部分建模.如果表格很宽,有很多列,这可能表明需要进一步规范化.不要害怕加入.学会爱加入.加入许多小表通常比查询和维护大型非规范化表更快.只有当您需要针对特定情况时才能进行非规范化,最好是通过物化视图…但是在您知道需要并且有实际的具体问题需要解决之前不要这样做.
对于自由形式和非结构化的用户贡献数据,请使用jsonb.它应该和hstore一样好,但它更灵活,更容易使用.
需要理解的一个相关的事情是：像jsonb上使用的GiST和GIN索引通常比普通的b-tree索引效率低得多.它们更灵活,但普通列上的b树索引几乎总是更快,更快.
