Re: more on delete from join

On Aug 28, 4:32 pm, paul c <toledobythe..._at_oohay.ac> wrote:
> Kevin Kirkpatrick wrote:
>
> ...
>
> >> By the way, why assume that CURRENT_USER
> >> is not updateable?
>
> > Great question, cuts to the heart of the matter:  It can't be updated
> > because it is a view.  It returns an conclusion, and it is not (IMO)
> > valid to assert conclusions. ...
>
> So A UNION B is a conclusion when assigned to a view, but not a
> conclusion when assigned to a base.  Where does this idea come from and
> what is it good for, apart from appearing to be a spurious reason to say
> that views aren't updateable?  Even if I were to accept that views
> aren't updateable, I'd ask why is CURRENT_USER necessarily a view?
>
> (Personally, I would prefer an engine that allows a user to log himself
> off by means of a simple delete rather than the usual arcane engine
> plumbing that introduces various environmental commands.  That way, the
> environment is forced to react to db changes rather than the other way
> around.  The engine becomes much simpler if this approach is followed
> and this is important if there's ever to be any progess in the aspects
> that today's engines slough off.)
> ...
>
>

My point, phrased another way, is: given base relvars A, B, and C with identical headings, this does not make sense:

(A UNION B) := (B UNION C) in the exact same way that this does not make sense:

int x, y;
x+y := 3;

Sure, in either case, the assignments *could* be carried out - in the former, A could just be assigned a value of all tuples in C... in the latter, x could be set to 1 and y could be set to 2. But nobody spends any amount of time writing a compiler that attempts to do so, for obvious reasons.

Even in cases where there are is no disambiguation, e.g.:

int x;
x+3 := 4;

we don't write compilers to evaluate that assignment by setting x:=1. For the same reason, just because sometimes evaluations like

(A UNION B) := {} only have one "solution", is no reason to allow them into the programming language so some super-genius compiler can assign A := {}; B:= {} whenever they are 1-solution solvable.

Anyway, perhaps the disconnect can be addressed better if you simply respond directly to this:

Does this make sense?
INSERT INTO (SELECT ENO FROM BOSS WHERE BOSS_ENO = 'E43' UNION SELECT ENO FROM BOSS WHERE ENO = 'E44') VALUES ('E12') If not, then how can you say that this makes sense:

CREATE VIEW A_NAME_FOR_A_QUERY
AS

   SELECT ENO FROM BOSS WHERE BOSS_ENO = 'E43'    UNION
   SELECT ENO FROM BOSS WHERE ENO = 'E44'; INSERT INTO A_NAME_FOR_A_QUERY VALUES ('E12'); ?

> conclusion when assigned to a base

>
> > It's kind of an aside to this conversation, but my underlying idea
> > here is that if a business rule differentiates between two parts of a
> > predicate, e.g. "Some people can update this column, but not that
> > column", then the data model should treat them as two separate
> > predicates.  ...
>
> Well, if you have two predicates and one isn't logically implied by the
> other, it's pretty much inescapable that you will need two relations
> even though the null advocates think not.  There is much in a user's
> predicate that the RM doesn't record, all it records are the variable
> names and constraints.  These and its chosen logical rules are all an
> execution engine has to go by.    I get the feeling that when many
> people talk about predicates or constraints, they don't bother to first
> try to write down an algebraic equivalent.  If they don't do that,
> really they are just throwing words around.
Received on Sat Aug 29 2009 - 00:38:56 CEST