Re: Attribute-values in separate table

From: paul c <toledobythesea_at_ooyah.ac>
Date: Mon, 29 Oct 2007 00:36:38 GMT
Message-ID: <qW9Vi.157677$1y4.54228_at_pd7urf2no>


-CELKO- wrote:

>>> It is a truly poor programmer indeed who would trade off data integrity for a faulty expectation of reduced work.  If there are eighty types of atomic facts, then whether you're coding for one table or for eighty, you still have to code for eighty types of atomic facts.  Is it really less work to lump it all together? <<

>
> It is much worse than that. Try to write a multi-purpose DEFAULT
> clause for all the attributes of those 80 different facts. Try to
> write a single CHECK() constraint for all the attributes of those 80
> different facts.
>
> The first one is impossible in SQL. The CHECK() constraint is
> possible but awful. I actually tried it for demo purposes. You start
> with a CASE expression for all of the possible domains in the little
> sample schema .. and hope that you never have more than five
> attributes.
>

Right! (That's why when you get into these re-inventions, you need to go all the way, like write a compiler to implement all the features you gave up when you treated the dbms like an access method. I think it's all because of lazy people after the fast buck who ignore the most important problem of any app, namely requirements. Even if it occurs to them to complete the re-invention, I suspect they would dodge that much harder work and end up with a kind of Tower of Hanoi explosive cost. Techies don't like the really hard work because that often involves emotional confrontations with people who don't and shouldn't speak their lingo, et cetera.) Received on Mon Oct 29 2007 - 01:36:38 CET

Original text of this message