From: "Mark Leith"
> Martijn Tonies wrote:
> >We're arguing about whether or not your database design
> >(as stored on disk) should contain NULLs.
> >IMO: no, or at least as few as possible.
> I believe the answer really is - *it depends*.
> You are both right, really. Martijn, yes, according to academia and
> proper database design, you should not really be using NULLs, (Rhino,
> see the writings of Chris Date and Fabian Pascal somewhere like
> www.dbdebunk.com, www.thethirdmanifesto.com etc.). Here's a good one:
Got that one ;)
The book I quoted is from Date, btw, and I enjoy reading it ...
> Of course, you're still going to pay $10-$15 for this..
> However, what is good for academia is *not* always good for the real
> world. Why store "Unknown" in a column for a table that could store
> millions, or billions, of rows, when you could simply allow a NULL (and
> save a *bunch* of disk space across your schemas) in the real world.
Well, the question still is if you should store "unknown" at all ;)
Not according to Date: you should store what is known. See the remarks
about the "true propositions", from which relational databases are derived
(but you probably know that).
> you can allow for the use of the NULL in the application, and *not* try
> to interpret it 5 ways from Sunday, then, in my honest opinion, a NULL
> would be acceptable.
> Short answer, as long as you do it without trying to get your
> application to handle them in many different ways, I don't see a great
> problem (when weighing them against extra costs, in both space and
> speed). If you can get away with not using NULL as well, then great.
I guess I can agree with that one.
> This argurment will, however, carry on between "academia" and "the real
> world" for at least the next 4000 years. :)
Until it gets replaced by a better model, but I don't expect that anytime
Database Workbench - development tool for MySQL, and more!
Database development questions? Check the forum!