It often happens that a particular pieces of information is non-null for a
small minority of cases. A superficially different manifestation of this is
when two pieces of information are identical in all but a small minority of
cases. This can be easily mapped to the previous description by
Kynn,
have you seen contrib/hstore ? You can have one table with common attributes
and hide others in hstore
Oleg
On Fri, 14 Mar 2008, Kynn Jones wrote:
It often happens that a particular pieces of information is non-null for a
small minority of cases. A superficially different manifestation
Kynn Jones wrote:
In all these cases, the design choice, at least according to RDb's 101, is
between including a column in the table that will be NULL most of the time,
or defining a second auxiliary column that references the first one and
holds the non-redundant information for the minority of
On Fri, Mar 14, 2008 at 3:46 PM, Heikki Linnakangas [EMAIL PROTECTED]
wrote:
tons of useful info snipped
From performance point of view, I would go with a single table with
NULL fields on PostgreSQL.
Wow. I'm so glad I asked! Thank you very much!
Kynn
On Fri, Mar 14, 2008 at 2:59 PM, Oleg Bartunov [EMAIL PROTECTED] wrote:
have you seen contrib/hstore ? You can have one table with common
attributes
and hide others in hstore
That's interesting. I'll check it out. Thanks!
Kynn
On Fri, 14 Mar 2008, Kynn Jones wrote:
On Fri, Mar 14, 2008 at 2:59 PM, Oleg Bartunov [EMAIL PROTECTED] wrote:
have you seen contrib/hstore ? You can have one table with common
attributes
and hide others in hstore
That's interesting. I'll check it out. Thanks!
actually, hstore was
