Re: Examples of SQL anomalies?
Date: Mon, 7 Jul 2008 05:25:12 -0700 (PDT)
On Jul 7, 1:30 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
> > On 6 juil, 17:46, "Brian Selzer" <br..._at_selzer-software.com> wrote:
> >> "Cimode" <cim..._at_hotmail.com> wrote in message
> >> > 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
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