Re: Examples of SQL anomalies?
Date: Wed, 02 Jul 2008 15:14:42 GMT
Message-ID: <CXMak.46666$kx.28164_at_pd7urf3no>
Bob Badour wrote:
> Ed Prochak wrote: >
>> On Jun 30, 5:54 pm, Marshall <marshall.spi..._at_gmail.com> wrote:
>>
>>> On Jun 30, 10:31 am, "Brian Selzer" <br..._at_selzer-software.com> wrote:
>>>
>>>
>>>
>>>
>>>> Well, the OP wanted examples of SQL anomalies, and you've just
>>>> confirmed a
>>>> big one.
>>>
>>>> If you have a bag that can contain peaches, but doesn't, then the
>>>> answer to
>>>> the question "How many peaches are in the bag?" is clearly zero. If
>>>> you are
>>>> asked by the accountant, "How much were we billed by AT&T this
>>>> month?" but
>>>> AT&T didn't send a bill, then the answer is clearly zero. That
>>>> SQL's COUNT
>>>> and SUM are something other than these common sense usages
>>>> exemplifies their
>>>> anomalous nature.
>>>
>>> [I meant to say this in my other post, but]
>>>
>>> Brian gets it exactly right here.
>>>
>>> Marshall
>>
>>
>> I'm not so sure about the AT&T bill. Consider the question may be
>> badly phrased:
>> "How much were we billed by AT&T this month?"
>> Is the amount being sought the amount on the bill received this month?
>> or the amount for this month's services?
>> If the question is asked July 1 and we haven't got the bill in the
>> mail yet, the answer must be "I don't know."
>> And who is the "we"? Are there multiple entities involved? (multiple
>> businesses owned by one parent company with separate phone accounts/
>> bills? or maybe a home business and personal home phone account both
>> shown on one bill?)
>>
>> So even in real life NULL (aka "I don't know") happens to be the
>> correct answer to some questions. It is not as clean cut as you and
>> Brian would like.
>> Ed
> > You are suggesting the computer should have some way to evaluate > external predicates. The computer cannot. Your argument is a red herring. > > If one expects a bill and the total is 0, that's just as useful to alert > one that the bill has not yet arrived as a NULL would be.
Yes, I don't want to belabour this more than it deserves, but there is only one result the rm can give to a question such as "what is on the AT&T bill?" and it is the same answer it would give to "do we have an AT&T bill?", ie., an empty relation. Bringing up such examples is plain trickery or common ignorance depending on the who suggests them.
In order to avoid being thought of as a nincompoop by one's co-workers, a db user should learn to avoid asking questions that db's can't answer and try avoid imagining that such questions are answerable. As Bob suggests, this is a basic condition for using a computerized db.
Many actual systems use a variety of exceptions so as to pretend that they can understand what Bob B calls external predicates, but such 'language' support is outside of the rm proper. The designers of such are kidding themselves if they think this can be done completely. Closure seems more important to me. Received on Wed Jul 02 2008 - 17:14:42 CEST