Re: All hail Neo!
Date: Wed, 26 Apr 2006 23:07:33 GMT
Message-ID: <V2T3g.66351$VV4.1268982_at_ursa-nb00s0.nbnet.nb.ca>
Marshall Spight wrote:
> It is worth noting that this is a *design* issue and
Which is why one should leave it to the designer. Give me a good logical
model to use, and if I wish the behaviour that null purports to give, I
will design it that way. Quite easily, I might add. And without the
> not a theoretical one per se.
> The semantics of SQL's
> null are well-defined, if rather clunky.
You and I use differing definitions of "well-defined".
> Likewise, my
> empty-set semantics are quite well established and
> theoretically sound. The question is, which one leads
> to the most useful software? I propose that a piece
> of software that refuses to run calculation on data you
> do have because of data you don't have is less useful
> that one that is not so pedantic.
Whoever posited such a stubborn creature? Certainly not I. Requiring someone to make an informed decision and an explicit statement about what to do when confronted with missing information is not at all the same as refusing to calculate.
Since this is a design
> issue, the only way to validate that assertion is through
> HCI testing, which I don't expect either side to perform.
What makes you think I have not performed those tests? I have directly observed hundreds of dbms users interacting with dbmses. I have been paid large sums of money to 'solve' problems caused by nulls and duplicate rows in existing designs. I have watched "hundred-million dollar+" projects succeed or fail over such nonsense.
I witnessed a hundred-million dollar family business that dominated its market fail over such nonsense.
> I also observe that argument-by-naive-user is not one
> I consider very strong, unless the software is designed
> specifically for naive users.
I include talented application programmers among the naive users of dbmses. Received on Thu Apr 27 2006 - 01:07:33 CEST