Re: "advanced" database design (long)

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Lew <lew(at)lwsc(dot)ehost-services(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: "advanced" database design (long)
Date: 2008-02-12 23:21:40
Message-ID: 1202858500.21589.37.camel@dogma.ljc.laika.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Sun, 2008-02-10 at 03:08 -0500, Lew wrote:
> SunWuKung wrote:
> > I always thought that having nullable columns in a table is a Bad
> > Thing (http://technet.microsoft.com/en-us/library/ms191178.aspx) and
>
> Ridiculous. The argument provided in that article is specious and likely SQL
> Server-specific. NULLable columns should occur wherever your data model calls
> for them, typically when you want to have a marker for "unknown" data. The
> advice in that article to move NULLable columns off to a separate table will
> actually cause worse, manual "special handling that increases the complexity
> of data operations" than the built-in and optimized handling the engine
> provides for NULLs. You should ignore this terrible advice.

I disagree that it's ridiculous. There are good arguments for avoiding
NULLs, not the least of which is that they can lead to very unintuitive
results from queries due to 3VL.

I think the passage in question (from the above URL) is reasonably good
advice. They recommend vertical partitioning to avoid NULLs, and I think
that is a very good design strategy in many cases.

> > I think its much better to avoid it whenever you have the info but
> > when you don't you just have to use the EAV model.
>
> Also ridiculous. You should never "have to use" the EAV so-called "model".

Agreed.

> question being described. The difficulty of conceptualizing data structures
> as EAV is one of the big strikes against it. The quoted citation evidences

Agreed. It has many other strikes as well: for instance, it's difficult
to form any kind of meaningful predicate for a relation in an EAV
design.

Regards,
Jeff Davis

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Ivan Sergio Borgonovo 2008-02-12 23:52:02 Re: end of life for pg versions...
Previous Message Bruce Momjian 2008-02-12 23:01:13 Re: [GENERAL] end of life for pg versions...