Re: MERGE as the imperative form of aggregation
- From: Bob Badour <bbadour@xxxxxxxxxxxxxxxx>
- Date: Mon, 16 Apr 2007 21:33:24 GMT
Marshall wrote:
On Apr 16, 10:24 am, Bob Badour <bbad...@xxxxxxxxxxxxxxxx> 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)
or
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.
Not necessarily.
The context-free
evaluation of (2) will transfer one row from client to server.
In (1), the server already has T -- all it needs is row. The question is can we devise an optimizer that recognizes such.
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.
Why do you think the operators must be hidden? If (1) and (2) are equivalent, presumably one can devise a constructive proof of such, which means one can devise a method to convert between them.
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.
I suggest distributed computing requires distributed optimization too.
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.
IMO, the early introduction of stored procedures retarded the development of several dbmses. Instead of fixing problems in the engine and the optimizer, vendors tended to offer stored procedure hacks to work around the problems.
I prefer to see a coupled language where the issue of whether the code is on the client or the server becomes irrelevant.
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.
I favor clarity over cleverness. How clear would it be?
.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
- References:
- MERGE as the imperative form of aggregation
- From: Marshall
- Re: MERGE as the imperative form of aggregation
- From: Aloha Kakuikanu
- Re: MERGE as the imperative form of aggregation
- From: Marshall
- Re: MERGE as the imperative form of aggregation
- From: Bob Badour
- Re: MERGE as the imperative form of aggregation
- From: Marshall
- MERGE as the imperative form of aggregation
- Prev by Date: Re: MERGE as the imperative form of aggregation
- Next by Date: Re: MERGE as the imperative form of aggregation
- Previous by thread: Re: MERGE as the imperative form of aggregation
- Next by thread: Where is everybody?
- Index(es):
Relevant Pages
|
Loading