Roy Hann wrote:
> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> news:1157989625.240604.102330_at_q16g2000cwq.googlegroups.com...
>> Well, clearly it could, and indeed should. It is extremely simple to
>> recognise Nulls as gibberish if one simply rewinds back to the
>> proposition being recorded. Consider that
>
> I think you have shown a few specific glitches without giving a proper
> appreciation of the full horror of the situation. From my point of view, as
> a practitioner slaving at the code face, THE overwhelming problem with being
> allowed to fob the DBMS off with a null is that it allows the (so-called)
> database designer to just sweep a whole lot of inconvenient details under
> the carpet.
>
> He "appears" to have produced a complete database design, and that
> appearance is reinforced by the fact that he can write an SQL script that
> will run without error to create a database. Unfortunately he's done next
> to nothing about capturing any understanding of what data the application
> will be expected to handle or what the application should (and should not)
> do with it. Instead of being forced to discover that there are, for
> example, six different types of customer, with different business rules, the
> database designer declares a one-shape-fits-all table with a lot of nullable
> attributes and leaves me to figure out what is really going on, and to write
> the giant tangle of code to make it happen. Gee, thanks. What a hero.
>
> I have come to suspect that *at least* 75% of the many tens of thousand of
> lines of code I see in a year are there only because some slack-ass DB
> designer didn't want to spec out a few more tables.
>
> Roy
>
>
Hear, hear. So rare to see the most important argument against nulls
stated, usually the arguments are degenerate technicalese. A DB with
nulls is most likely incomplete. Told this, even the most incompetent
exec' ought to be able to ask the right question about the latest design.
p
Received on Mon Sep 11 2006 - 18:38:32 CDT
