Re: MERGE as the imperative form of aggregation

From: Brian Selzer <brian_at_selzer-software.com>
Date: Mon, 16 Apr 2007 06:05:45 GMT
Message-ID: <ZmEUh.6489$5e2.5859_at_newssvr11.news.prodigy.net>


"paul c" <toledobythesea_at_oohay.ac> wrote in message news:yGCUh.82245$aG1.56433_at_pd7urf3no...
> Brian Selzer wrote:
> ...
>> Update may be "ugly," but it's a necessary and primative operation. It
>> is not just a combination of insert and delete. Because a key value can
>> only be used to identify a tuple in single database state, update
>> provides the means to correlate the tuples in the preceding state with
>> those in the succeeding state so that transition constraints can be
>> enforced.
> ...
>
> Whenever I've heard people say that update is not a combination of delete
> and update, without exception they've failed to describe it using any kind
> of fundamental algebra or calculus.

That's because you appear to have bought into the erroneous notion that a relational database is a collection of relation variables. Information is lost when transforming an insert or a delete or an update or some combination of them into an assignment--especially when you add multiple assignment into the mix. As a result, you can't determine what is different between successive database states, and consequently, you can't define transition constraints. This thinking is backwards. Assignment is not primative. It is a combination of the primatives delete and insert, since all of the information in a relation is replaced. It should be obvious that no information is lost when transforming an assignment into a delete and an insert. As for update, I refer you to the example I provided later on in the previous post. Update provides correlation between tuples in successive database states. This correlation is lost when transforming an update into a delete and an insert.

> Once, I even heard it described as the equivalent of replacing the upper
> metal on a traffic stop sign, the notion being that the post holding up
> the sign stayed intact.
>
> That is why I continue to think that UPDATE is a creation of a dbms's
> environment and no more than that. Nothing wrong with such convenient
> devices, but they are not fundamental. Any equivalence that is present
> resembles low-level assembler macros, not the model itself.
>
> INSERT is clearly the rm's set union and DELETE a conjunction of a
> negation.
>
> p
Received on Mon Apr 16 2007 - 08:05:45 CEST

Original text of this message