So because $SOLUTION can't do both $FEATURE1 and $FEATURE2, you don't use $SOLUTION and thus you don't even have $FEATURE1?
Hstore is invaluable when you want to add arbitrary attributes to rows in your tables (think: different attributes for products in different categories). It's as if every row had an unlimited (and different from other rows) amount of columns.
To do this without hstore, you can dump the additional data as a serialized blob of some kind, but then you lose the ability to efficiently[1] query or sort for those additional attributes or you use a complicated mess of join tables, which means increasing cost of querying as you add more fields to query for (one join per field).
With hstore, you get indexed querying and sorting in addition to an unlimited amount of fields.
Also: because keys and values are just strings, it's in fact possible to nest hstores, you just don't get the nice indexing or any kind of type safety past the first level of hstores.
[1] if your blob is XML or JSON (via pl/v8), you can use functional indexes to still get indexed and sorted lookups in advance without having to do the indexing inside the application logic which you would have to in case of any of the NoSQL stores.
> So because $SOLUTION can't do both $FEATURE1 and $FEATURE2, you don't use $SOLUTION and thus you don't even have $FEATURE1?
More like I choose $SOLUTION2 that can do $FEATURE{1,2}. Maybe that's adding related tables, maybe it's using a JSON column, maybe it's something else. I think part of good engineering is picking solutions that keep your options open. It seems like your data's structure always gets more complex over time, so hstore is a risky choice.
I'm not saying it's a terrible choice: you could always manage the flatness the way people use Java properties files, with compound key names to simulate fancier data structures, but that's sort of a pain. I could definitely see myself trying out hstore in the future for something like user preferences; I just am hesitant due to its flatness.
> because keys and values are just strings, it's in fact possible to nest hstores
I don't understand this; could you elaborate? Are you saying that an hstore is really a string?
Hstore is invaluable when you want to add arbitrary attributes to rows in your tables (think: different attributes for products in different categories). It's as if every row had an unlimited (and different from other rows) amount of columns.
To do this without hstore, you can dump the additional data as a serialized blob of some kind, but then you lose the ability to efficiently[1] query or sort for those additional attributes or you use a complicated mess of join tables, which means increasing cost of querying as you add more fields to query for (one join per field).
With hstore, you get indexed querying and sorting in addition to an unlimited amount of fields.
Also: because keys and values are just strings, it's in fact possible to nest hstores, you just don't get the nice indexing or any kind of type safety past the first level of hstores.
[1] if your blob is XML or JSON (via pl/v8), you can use functional indexes to still get indexed and sorted lookups in advance without having to do the indexing inside the application logic which you would have to in case of any of the NoSQL stores.