Re: Requirements for update languages?

"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> writes:

> "Jens Lechtenbörger" <lechtej_at_uni-muenster.de> wrote in message
> news:m2k7jo87eh.fsf_at_pcwi1068.uni-muenster.de...
> > Dear reader,
> >
> > while there are some criteria to assess relational query languages
> > (adequate, relationally complete, optimizable) I wonder what makes a
> > good update language for a data model.
> >
> > In particular, I wonder about the following points in SQL.
> >
> > 1. I believe that SQL data manipulations are not adequate for bags,
> > as they lack the ability to manipulate duplicates. (E.g., you
> > can neither delete 3 out of 5 duplicates nor insert 3 duplicates
> > at once.)
>
> General comment on bags: There are no such things.

Just to settle the issue: They exist. I created them in IBM DB2 UDB. You work at IBM, don't you? ;)

> If two things are *identical in all respects* then they *are the
> same thing*. If they are not identical in all respects and you
> choose to hide the piece(s) of information that distinguishes
> them, then you break the information principle and frankly deserve
> what you get.

In tables I don't need to represent "all respects". The easiest example I can think of is my *bag* of items bought in a supermarket. It might contain two boxes of beer (if it was big enough for boxes of beer, of course). I don't care to tell them apart and the supermarket's bar code reader doesn't either. The bar code reader just inserts two identical tuples into some table, exactly as they will be printed on my receipt.
(Of course, the designer could choose to maintain a duplicate counter. Your arguments here...)

I don't think that it helps to neglect the existence of bags. In fact, I never *used* bags myself (my real tables, except for the duplicate-existence-proof, have primary keys), and I don't think other people should use them. However, SQL by default has bag semantics. Period.
Hence, in the past I got asked by anonymous referees whether my results are valid for set semantics or for bag semantics or both. When addressing such a review I'm definitively in bad luck if I say that it's stupid to use bags or to think about bag semantics... In contrast, arguments like (1.) in my original posting above should help people see why bags in SQL are a bad idea.

> > 2. As a db user, I expect that I can undo (inadvertent) data
> > manipulations, e.g., undo an insertion via a deletion or vice
> > versa.
> > Does anybody else believe that this is a reasonable requirement?
>
> No, I believe that is highly unreasonable. I you buy 5,000,000
> shares you cannot just say, opps, didn't mean to do that -
> backout, you must sell them and hope you don't loose money.

OK. I want to have the ability to undo my updates *in theory*. Practical, legal, whatever issues might prevent me from actually undoing them.

> > 3. As a db admin, I expect that users know what they are doing when
> > they manipulate data.
> > Does anybody else believe that this is a reasonable requirement?
>
> No, I believe that is highly unreasonable. If all my database
> users had to pass am exam before using the db and had to sign a
> legally enforceable grantee that they know what they are doing,
> then I would not have very many db users. ;-)

So, it's "highly unreasonable" because you could loose your job?

> > Basically, the anonymous referees did not buy (2) and (3).
>
> I don't blame them.

When writing up another posting in this thread, where I summarized the critique, I realized that only 1 out of 4 did not by (2) and (3). 1 did, the other 2 seemed to expect more theorems for that conference.

Regards,

Jens Received on Sat Nov 09 2002 - 23:46:57 CET