Re: Requirements for update languages?

"Jens Lechtenbörger" <lechtej_at_uni-muenster.de> wrote in message news:m2wunmmkda.fsf_at_pcwi1068.uni-muenster.de...
> > 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? ;)

Depends what you call a bag. Duplicate rows in SQL tables not *identical in all respects*, it's just that you have choosen to hide the piece(s) of information that distinguishes

I might work for IBM, but I can't be blamed for SQL.

> > 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

You do care insofar as you need to know that when you have counted one of them, you only have one more left to count. If you care that there are two beers, you need to be able to tell them apart.

> and the
> supermarket's bar code reader doesn't either.

No, although it would be nice if it could. Would stop any possiablity of getting double charged by a sneaky assistent scanning a given item twice.

> The bar code reader
> just inserts two identical tuples into some table, exactly as they
> will be printed on my receipt.

But they are NOT identical on your reciecpt. One will below the other. If they were idential then there would just be one of them! On the table, one is 'later' than the other.

> (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.

If only we could! but even using SQL with PKs, SELECT DISTINCTs etc, you still have to (occasionally) worry about bags.

I think it does help to continually point out the absurdity of bags, and the obvious lack of existence of two things that are identical in all respects but that are not the same.

> 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...

Well I hope you at least tried to say that they are stupid.

> In contrast, arguments like (1.) in my original posting above should
> help people see why bags in SQL are a bad idea.

Fair enough, but I think we have plenty of evidence already.

Hands up who thinks bags are a good 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.

Yes, I would agree with that sentiment. Baring database constraints to the contrary ,we should, be able to undo updates.

> > > 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?

Well that is one way of finding out that you we wrong to assume users are sensible when you design a system.

It all depends on what you mean by "users know what they are doing when they manipulate data". Users usually have a vague notion of what they want to do, but they don't always "know what they are doing". However they are very good at learning with time, and if you can present them with a clear, transparent and logical system that exhibits a lot of conceptual integrity, they will quickly come to know *exactly* what they are doing.

Regards
Paul Vernon
Business Intelligence, IBM Global Services Received on Mon Nov 11 2002 - 14:16:06 CET