在完成关系DB / NoSQL研究辩论之后，我得出的结论是，我将继续将PG作为我的数据存储。该决定的一个重要部分是宣布JSONB达到9.4。我的问题是我现在该怎么办，从头开始构建一个应用程序，知道我想要迁移到（我的意思是现在就使用！）jsonb？对我来说，DaaS选项将会持续运行9.3。
据我所知，并纠正我如果我错了，hstore会运行得更快，因为我会在hstore列中对很多键进行大量查询，如果我要使用普通json我无法利用索引/ GIN等。但是我可以利用json嵌套，但运行任何查询都会非常慢，用户会感到沮丧。
那么，我是否围绕当前版本的hstore或json数据类型，“good ol”EAV或其他东西构建我的应用程序？我应该以某种方式构建我的数据库和应用程序代码吗？任何建议将不胜感激。我相信其他人可能会面临同样的问题，因为我们等待PostgreSQL的下一次正式发布。
我想要构建的应用程序的一些额外细节：
- 非常关系（下面有一个例外）
- 强大的社交网络方面（团体，朋友，喜欢，时间表等）
- 基于具有可变用户分配属性的单个对象，可能是10或1000+（这是无模式设计需要发挥作用的地方）
提前感谢任何输入！
答案 0 :(得分：12)
这取决于。如果您希望拥有大量用户，非常高的交易量，或每个查询的疯狂数量的属性提取，我会说使用HSTORE。但是，如果您的应用程序从小开始并随着时间的推移而增长，或者只有相对较少的获取属性的事务，或者只是为每个查询获取一些，那么请使用JSON。即使在后一种情况下，如果您没有获取许多属性，但经常在查询的WHERE子句中检查一个或两个键，则可以创建一个功能索引来加快速度：
CREATE INDEX idx_foo_somekey ON foo((bar ->> 'somekey'));
现在，当你有WHERE bar ->> somekey时，它应该使用索引。
当然，使用嵌套数据并在可用时升级到jsonb会更容易。
所以我会倾向于使用JSON，除非你确定在你有机会升级到9.4之前你会大量使用关键提取来踢你的服务器的屁股。但是为了确保这一点，我会说，现在对预期的查询量做一些基准测试，看看什么最适合你。
答案 1 :(得分：3)
你可能没有给出足够详细的回答，但我会这样说......如果你的数据是非常关系的，那就是＃34;那么我相信你最好的方法就是用良好的关系设计来构建它。如果它只是一个带有＆＃34;变量分配属性＆＃34;的字段，那么这对于hstore来说听起来很好用。在这一点上，这是非常尝试和真实的。我已经在9.4上做了一些阅读，jsonb听起来很酷，但是，它已经有一段时间了。我怀疑9.3中的良好模式设计+对hstore的非常有针对性的使用可能会产生良好的性能和灵活性组合。