Re: Requirements for update languages?

If by bags you mean online shopping bags/carts, I believe that there shouldn't be duplicate items. There should be an item and an associated quantity. Just my opinion.

"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.)
>
> 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?
>
> First, it is not clear whether this is true for base
> relation updates. E.g., consider relation R(A,B) with an
> assertion "check 2 < select count(*) from R where A=1" in bag
> instance { (1,0), (1,0), (1,0) } and insertion of (1,0) into this
> instance. As duplicates are not treated well by SQL, an undo of
> that insertion is difficult. I guess that the only way is to
> issue a transaction that first deletes everything and then
> re-inserts the desired tuples. Clearly, this works in theory,
> but is not a desirable way to go in practice.
> Second, in the presence of view updates, problems arise much more
> naturally (without duplicates). E.g., users cannot undo
> deletions from projections, as information about the missing
> attributes is not available.
>
> 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?
>
> Again, for view updates this is often not the case. E.g., in case
> of projections users delete tuples they do not know completely;
> in case of deletions from unions they do not even know from which
> relation something gets deleted.
>
> It turns out that (2) and (3) above are equivalent. I wrote a paper
> about this issue, where I warn against using view updates. If you
> are interested, take a look at:
> http://dbms.uni-muenster.de/publications/downloads/view-updates.pdf
> A small warning: An almost identical version of that paper got
> rejected at ICDT'03. Basically, the anonymous referees did not buy
> (2) and (3).
>
> I'm curious to see your opinions.
>
> Jens
Received on Fri Nov 08 2002 - 22:09:15 CET