Re: MERGE as the imperative form of aggregation

On Apr 16, 10:24 am, Bob Badour <bbad..._at_pei.sympatico.ca> wrote:
> Marshall wrote:
>
> > So that's what got me to thinking about trying to make a
> > closer correspondence between the imperative and algebraic
> > operators. I have to say I find the idea appealing.
>
> If one has assignment and if one has the algebraic operators, what does
> one lack?

One lacks imperative statement(s) that are efficiently implementable in a distributed context. Ordinarily that wouldn't bother me much, but the severity of this issue makes me want to include finer grained imperative operators in the model.

For example, suppose I want to insert one row into a table with a million rows. Assume the below executes on a client machine, and the relvar T is on a distinct server machine.

  T = T union row                       (1)

  insert T row                            (2)

Introducing context sensitivities into expression evaluation rules is a bad idea. In the above, the context-free evaluation of (1) will transfer one million rows from server to client, and one million and one rows from client to server. The context-free evaluation of (2) will transfer one row from client to server.

If we reluctantly abandon context-free expression evaluation, we now have to either 1) come up with a theoretic framework that can transform any assignment into a comparably efficient set of operations under the covers, using some hidden imperative operators that will probably look a lot like insert, delete and maybe update, or else 2) accept some hideous network inefficiencies. I don't know how to do 1) and I don't want to do 2).

Alternatively, we could just directly support insert/delete/whatever in the kernel language. This seems the better choice.

Certainly assignment is a very clean way to describe the abstract semantics of any imperative operators one cares to define. However that alone is not sufficient reason to include or even allow it in the concrete kernel language. If one was not thinking in terms of distributed computing, this consideration would not apply. However my interests include distributed operation.

> >>Next, there are insert, update, and delete triggers. Now merge is
> >>expected to be combination of insert, update; naturally insert and
> >>update triggers are expected to be fired when issuing a merge
> >>statement?
>
> > Triggers, sigh. I have a poor grasp of what they are for and
> > what they mean from a theoretical standpoint. What are they
> > necessary for?
>
> Very little. Something like them may be required to resolve
> ambiguity in view updates.

Is that pretty much it? (That's my impression.) Because if so it might be the case that some other mechanism could accomplish that, (and notification) and we could just ditch the idea of triggers completely.

> > I have seen good descriptions of how to
> > express view updating as triggers that model the inverse
> > view, but would that be necessary if we had full view updating
> > in the engine?
>
> I suppose that depends on what you mean by "full view updating". It
> strikes me that some view updates are ambiguous. How does "full view
> updating" resolve the ambiguity?

It doesn't, but I have an idea in mind (incompletely developed) that might allow the possibility of these ambiguities to be resolved according to how the view expression was written.

> > What are triggers necessary for? I am clear
> > on the value of *notification* of changes being sent to other
> > components, but *actions* are less clear to me. Especially
> > "instead of" actions.
>
> Triggers can automate the correct method for preserving invariants under
> certain transformations. For example, one may decide to present some
> group of users with an interface that allows them to simply delete any
> invoice from their view regardless of the constraints and even without
> deleting any tuples in base relations.

Interesting! I'll have to think about that some more.

Marshall Received on Mon Apr 16 2007 - 22:49:08 CEST