[OSM-dev] Is there a way to use simple schema without hstore
andreaskalsch at gmx.de
Fri Nov 19 09:25:37 GMT 2010
Am 19.11.10 10:06, schrieb Frederik Ramm:
> 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
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:
My personal point is that my system relies on the 0.36 schema and I simply cannot change all
>> 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?
More information about the dev