Re: relative complement?

On 19 mrt, 01:30, paul c <anonym..._at_not-for-mail.invalid> wrote:

> I think you're no more biased than Date is when he advocates multiple
> assignment.  I can see that you need some language feature like that if
> your chosen environment includes the ability to make relation values
> persistent on the fly.
> - Tekst uit oorspronkelijk bericht weergeven -

Paul,

D(&D)'s reasons for advocating multiple assignment are amply documented, and they have _nothing_ to do with "persistence", on the fly or not.

The thing is (, they say, ) let's assume that "temprorary inconsistencies" (database states that are in violation of some constraint) are allowed to be "seen" by the program that created them. That is, let's assume that a scenario is possible in which a program issues a DML statement DML1 that gives rise to an inconsistent database state, then regains control, does whatever it sees fit to do, then issues a DML statement DML2 that dispenses with the inconsistency.

How can you guarantee that "whatever that program saw fit to do", would not ultimately produce information that is (in whatever indirect way) dependent on the inconsistency created, and how can you guarantee that such information, "derived from an inconsistency", does and will not propagate to other programs via mechanisms outside the control of the DBMS (such as queues, pipes, sequential files, LU62 connections, ...) ? Such that the inconsistency will ultimately be visible to the entire world nonetheless ? Received on Sun Mar 27 2011 - 22:32:17 CEST