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

Andreas Kalsch andreaskalsch at gmx.de
Fri Nov 19 09:25:37 GMT 2010


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

My personal point is that my system relies on the 0.36 schema and I simply cannot change all 
dependant scripts.
>
>> But just intermingling things for fun does not make the world better.
>
> I think you're misunderstanding. hstore has not been implemented for fun. (Are you aware that 
> PostgreSQL can extend column indexes to hstore keys?)
Probably I am wrong ... yes I know that you can index hstore with a GIST.
>
>> MongoDB, for example, unifies worlds by simply using JSON. I don't have to manually parse things 
>> I do not need to parse.
>
> In turn, you will have a hard time getting the performance required for a planet-wide application 
> out of MongoDB.
OK, can you explain further what the bottlenecks would be?
>
> Bye
> Frederik
>




More information about the dev mailing list