Re: Examples of SQL anomalies?

From: Cimode <cimode_at_hotmail.com>
Date: Mon, 7 Jul 2008 05:25:12 -0700 (PDT)
Message-ID: <b6313a3d-a07c-40d7-859c-6c70db4fa0c9_at_f63g2000hsf.googlegroups.com>


On Jul 7, 1:30 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> news:623888cb-7e35-4aaf-a496-1654f8fed040_at_k37g2000hsf.googlegroups.com...
>
>
>
> > On 6 juil, 17:46, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> >>news:f4a29563-3e69-4d50-a3d8-07d434aac374_at_27g2000hsf.googlegroups.com...
>
> >> > On 6 juil, 15:43, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> > [Snipped]
> >> >> >> The users know what the data is supposed to mean. The system
> >> >> >> hasn't a
> >> >> >> clue.
> >> >> > I do not understand how you place system and people on the same
> >> >> > standpoint. Don't you believe in need-to-know basis?
>
> >> >> What has that to do with it?
> >> > Everything. Why do you want to place the burden of data interpretation
> >> > on people at run time. What is the point designing systems to present
> >> > information to people if they have to spend hours guessing what it
> >> > means?
>
> >> I would place the burden of data interpretation on people because it is
> >> only
> >> people that can interpret data.
> > OK but do they need to do it at run time. What would be the point of
> > design then?
>
> In some cases, yes, they need to do it at run time. With an unlimited
> budget of time and money, you can handle every possible exception in code,
> but back here in the real world, you can't waste precious resources on
> something that seldom occurs, so you just print out an exception report and
> provide the means for the users to deal with them (if it doesn't already
> exist).
Who says design should be unlimited? Design simply sufficient to handle most cases and it should correct on RM standpoint. What about time wasted on poor design?

> >> Why would they have to spend hours? Hopefully any system would present
> >> enough complete information to obviate most guesses, but for the rest,
> >> given
> >> a choice between being given a potentially wrong answer and being told
> >> that
> >> the information is incomplete, I (and most people I know) would prefer
> >> the
> >> latter, even if it required a little extra effort on my part.
> > But then, following this logic and the 8 item weigth example, the
> > system would then require the information that the sum is relevant
> > only up to 8 items to be available to people for them to make
> > *educated* guesses. Don't you think that makes things more
> > complicated? Most people I know would tell you, you did a poor design
> > job and that they don't need this irrelevant information.
>
> The information is already available. If SUM returned an indeterminant
> result, then the user should be able to issue additional queries qualified
> with something like, WHERE weight IS NULL or WHERE weight is NOT NULL, in
> order to find out why the result was indeterminant. It certainly isn't
> rocket science.
But what user are you refering the end user or the designer? Should an application end user have to know about IS NULL / IS NOT NULL? Received on Mon Jul 07 2008 - 14:25:12 CEST

Original text of this message