[OSM-dev] Is there a way to use simple schema without hstore

Brett Henderson brett at bretth.com
Sat Nov 20 00:47:20 GMT 2010

On Fri, Nov 19, 2010 at 8:25 PM, Andreas Kalsch <andreaskalsch at gmx.de>wrote:

> Am 19.11.10 10:06, schrieb Frederik Ramm:
>  Hi,
>> Andreas Kalsch wrote:
>>> 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,
>> 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.
> 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.
> It's only one step away from switching to a document store.
> Example for unnessessary complex schema design:
> http://wiki.openstreetmap.org/wiki/DE:HowTo_minutely_hstore

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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20101120/13b1d64f/attachment-0001.html>

More information about the dev mailing list