Re: On specialization constraints time of application

From: Brian Selzer <brian_at_selzer-software.com>
Date: Sun, 14 Jun 2009 11:04:41 -0400
Message-ID: <dk8Zl.13248$im1.2242_at_nlpi061.nbdc.sbc.com>


"Cimode" <cimode_at_hotmail.com> wrote in message news:45ad2a8a-f252-454c-aa7d-d602be7508e1_at_i28g2000prd.googlegroups.com...
> Snipped
> > The world of practice is full of people whose professional development
> > consists almost entirely of OOP, and who are suddenly coming up to speed
> > on
> > both SQL and database design. Not only that, but they have a very short
> > deadline to produce deliverables, and an intentionally narrow view of
> > the
> > value of stored data. These people often unconsciously associate
> > meanings
> > with nulls that go way beyond anything that you or the experts you cite
> > would accept as a useful meaning for that symbol. If you ask them, they
> > will revert to the meaning that they attach to a pointer that doesn't
> > point
> > anywhere. In that world, promoting some sort of "best practice" in
> > restricting the use of null tends to fall on deaf ears.
> Time constraints are not a good excuse for doing poor design since
> using NULLS will crunch time over the entire system lifecycle. For
> instance the time of maintainance of a system using NULLS is far more
> important than a system that does not use them, increasing TCO by
> orders of magnitude.
>
> Because they ignore RM definitions about, SQL developpers also ignore
> that drawbacks of using nulls far outweights any advantages.

I would have used 'misusing nulls' instead of 'using nulls' because judicious use of nulls can actually reduce both development and execution time, as well as maintenance, especially if decomposition would introduce complicated interrelational constraints. For example, a schema for married employees,

MarriedEmployees {EMP#, NameOfSpouse}

where NameOfSpouse can be null is a lot easier to maintian than a pair of schemata,

MarriedEmployeesWithSpouseName {EMP#, NameOfSpouse}, MarriedEmployeesWithoutSpouseName {EMP#}

and the interrelational constraint that prevents an instance of EMP# from appearing in both relations.

> Promoting best practices can not replace a formal education about RM.

But what counts as 'formal education' these days is in many cases worse than being worthless. Received on Sun Jun 14 2009 - 17:04:41 CEST

Original text of this message