Re: 3 value logic. Why is SQL so special?
From: paul c <toledobythesea_at_oohay.ac>
Date: Mon, 11 Sep 2006 23:38:32 GMT
Message-ID: <YrmNg.543866$IK3.13955_at_pd7tw1no>
>
> 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
>
>
Date: Mon, 11 Sep 2006 23:38:32 GMT
Message-ID: <YrmNg.543866$IK3.13955_at_pd7tw1no>
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 Tue Sep 12 2006 - 01:38:32 CEST