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