From: | "Pierre C" <lists(at)peufeu(dot)com> |
---|---|
To: | "Merlin Moncure" <mmoncure(at)gmail(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Postgres NoSQL emulation |
Date: | 2011-05-11 11:14:46 |
Message-ID: | op.vvbdiwdceorkce@apollo13 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> why even have multiple rows? just jam it all it there! :-D
LOL
But seriously, when using an ORM to stuff an object hierarchy into a
database, you usually get problems with class inheritance, and all
solutions suck more or less (ie, you get a zillion tables, with assorted
pile of JOINs, or stinky key/attributes schemes where all attributes end
up as TEXT, or a table with 200 columns, most of them being NULL for a
given line).
NoSQL guys say "hey just use NoSQL !".
In a (common) case where the classes have some fields in common and othen
searched, and that the DB needs to know about and access easily, those
become columns, with indexes. Then the other fields which only occur in
some derived class and are not very interesting to the DB get shoved into
a hstore. The big bonus being that you use only one table, and the "extra"
fields can still be accessed and indexed (but a little slower than a
normal column). However I believe hstore can only store TEXT values...
Could be interesting. Or not.
From | Date | Subject | |
---|---|---|---|
Next Message | Mason S | 2011-05-11 11:56:51 | Re: partition query on multiple cores |
Previous Message | Prodan, Andrei | 2011-05-11 11:08:44 | 'Interesting' prepared statement slowdown on large table join |