Re: relative complement?

From: Erwin <e.smout_at_myonline.be>
Date: Fri, 18 Mar 2011 16:36:05 -0700 (PDT)
Message-ID: <53f2155d-1f47-43ac-a26b-d7dfe02515f3_at_w7g2000yqe.googlegroups.com>


On 18 mrt, 22:44, paul c <anonym..._at_not-for-mail.invalid> wrote:

> Given their chosen languages I don't fault
> them, it's just that I don't think all possible languages need those
> concepts, eg., a functional language might depend on side-effects for
> recording relations.

I suspect your "side-effects" are what Date calls "cheating" when it comes to functional languages and how they do I/O.

At any rate, every single bone in my programmer's body tells me sideeffects  are bad news. They are the pest AND the cholera. They are variables existing (AND being updated !!!!) without having been declared. Therefore, they are about not knowing the full results of the execution of your program. And "not knowing the full and complete result" is nothing more than, in a mathematical sense, not being truly functional to begin with !!! You can call me biased if you want to.

> As long as such side-effects don't allow logical
> inconsistencies it wouldn't bother me.

But how would you prove absence of such inconsistencies ? If you consider that the inconsistencies might appear only in the existing- -undeclared-variables that get updated "only as a side-effect" ?

> Eg., I don't know why Date
> suggests 'deleting from both sides' is 'appropriate' as often as he
> suggests it is

One argument that is VERY strong, imo, is that if JOIN is commutative (which it is), then A JOIN B is the very same thing as B JOIN A (the _expressions_ are not identical, but the _value_ they _evaluate to_ are indeed guaranteed to be identical, and it is of course only that _value_ we are ever interested in), and it would therefore be extremely desirable for a view updating mechanism to treat a delete from A JOIN B in guaranteeably the same fashion as a delete from B JOIN A. At least in the case where the system is not considering the effect that any of the three possible solutions might have regarding constraint violations, the only option that guarantees this behaviour is the symmetric one.

But I'm sure you're aware of that argument already.

> Lots of times it seems to me
> perfectly logical and not ambiguous to 'delete' from only one 'side'.

Based on what ?

Awareness of certain constraints that exist in the database you happen to be looking at ?

(Note that RI constraints are usually taken as a very strong suggesting factor in deciding how to interpret a delete-through-join request. "Delete the 'one' side only if the tuple(s) deleted on the 'many' side is(are) the very last one(s)." is a very common example. But can you prove that you can deduce the existence of a 1-n RI constraint from any set of arbitrarily formulated constraint expressions (as opposed to the traditional 'explicit' FK declarations) ?

> I think one could write an engine that
> naively implemented the equivalent of join deletes and union inserts
> without inconsistencies and it would be naive only in the sense that it
> had very ponderous aka slow behaviour.

It is precisely that kind of naive that I was referring to. And remembering what you once wrote about someone hooking a RACF call into an SMF call (or was it the other way round ?), I'm surprised you seem to consider the building of "naive" engines a worthwhile option.

> Much as I'd like to see it again, not having what most
> people would call income, that seems unlikely.

Seems like lack of income is a common characteristic among DB talents. Received on Sat Mar 19 2011 - 00:36:05 CET

Original text of this message