Postgresql JSONB is coming. What to use now? Hstore? JSON? EAV?

前端 未结 2 1259
梦谈多话
梦谈多话 2021-01-31 10:31

After going through the relational DB/NoSQL research debate, I\'ve come to the conclusion that I will be moving forward with PG as my data store. A big part of that decision wa

相关标签:
2条回答
  • 2021-01-31 10:56

    You probably don't give quite enough to give a very detailed answer, but I will say this... If your data is "very relational" then I believe your best course is to build it with a good relational design. If it's just one field with "variable assigned attributes", then that sounds like a good use for an hstore. Which is pretty tried and true at this point. I've been doing some reading on 9.4 and jsonb sounds cool, but, that won't be out for a while. I suspect that a good schema design in 9.3 + a very targeted use of hstore will probably yield a good combination of performance and flexibility.

    0 讨论(0)
  • 2021-01-31 10:59

    It depends. If you expect to have a lot of users, a very high transaction volume, or an insane number of attribute fetches per query, I would say use HSTORE. If, however, you app will start small and grow over time, or have relatively few transactions that fetch attributes, or just fetch a few per query, then use JSON. Even in the latter case, if you're not fetching many attributes but checking one or two keys often in the WHERE clause of your queries, you can create a functional index to speed things up:

    CREATE INDEX idx_foo_somekey ON foo((bar ->> 'somekey'));
    

    Now, when you have WHERE bar ->> somekey, it should use the index.

    And of course, it will be easier to use nested data and to upgrade to jsonb when it becomes available to you.

    So I would lean toward JSON unless you know for sure you're going kick your server's ass with heavy use of key fetches before you have a chance to upgrade to 9.4. But to be sure of that, I would say, do some benchmarking with anticipated query volumes now and see what works best for you.

    0 讨论(0)
提交回复
热议问题