Re: more on delete from join
Date: Fri, 28 Aug 2009 21:32:49 GMT
Kevin Kirkpatrick wrote:
> 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.)
> 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 Fri Aug 28 2009 - 23:32:49 CEST