Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
To: "Merlin Moncure" <mmoncure@gmail.com>
Cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Subject: Re: Postgres NoSQL emulation
References: <op.vu91fpoyeorkce@apollo13>
	<BANLkTikU3VosAWzi1tB3O9xMbgz1s-8kPg@mail.gmail.com>
Date: Wed, 11 May 2011 13:14:46 +0200
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Pierre C" <lists@peufeu.com>
Message-ID: <op.vvbdiwdceorkce@apollo13>
In-Reply-To: <BANLkTikU3VosAWzi1tB3O9xMbgz1s-8kPg@mail.gmail.com>
User-Agent: Opera Mail/11.10 (Linux)


> 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.