<div class="gmail_quote">On Fri, Nov 19, 2010 at 8:25 PM, Andreas Kalsch <span dir="ltr"><<a href="mailto:andreaskalsch@gmx.de">andreaskalsch@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Am 19.11.10 10:06, schrieb Frederik Ramm:<div class="im"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Hi,<br>
<br>
Andreas Kalsch wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
One simple answer: The drivers do not work appropriately with complex SQL data types. In PHP or node.js I will get a string that I have to parse, in MongoDB, I get a proper object or list. If I used hstore in a consequent way (I like consequence and unification), I would have sets in sets,<br>

</blockquote>
<br>
It seems to me that you are mistaking "consequence" for "exaggeration". In many cases - especially when dealing with large real-world datasets as opposed to a nice little hello-world application -, a healthy compromise works better than grabbing one concept and trying to make the world fit that concept.<br>

</blockquote></div>
I am sure there are some good uses for hstore, but as soon as you use it, you are waiting for something like a document-oriented database. I ask myself: Why do I need normal columns when there is hstore? Of course there are some answers like special indexing ... the fact: Intermingling both concepts inside one database will make queries and schema design more complex than necessary - many, many time-consuming choices you do not need to do in the NoSQL world. If you take a look at all Postgres data types, you have a myriad of choices. Often, a simple design will win, especially when you will build something more complex on top of it.<br>

It's only one step away from switching to a document store.<br>
Example for unnessessary complex schema design: <a href="http://wiki.openstreetmap.org/wiki/DE:HowTo_minutely_hstore" target="_blank">http://wiki.openstreetmap.org/wiki/DE:HowTo_minutely_hstore</a><br></blockquote><div><br>
Please keep in mind that the one and only reason I've switched to hstore is performance.  It has nothing to do with any perceived improvements in schema design or adherence to an alternative data storage philosophy.  It most certainly wasn't done for fun ;-)  I only switched after spending many days trying alternate ways of indexing the database, waiting (in some cases for several days) for full index builds to occur, and re-running benchmarks to measure improvements.  It was an incredibly tedious and frustrating experience that I only continued with in order to make the database scale more effectively to planet sized datasets.<br>
</div></div><br>Brett<br><br>