> 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?
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?