Re: Distributed foreign keys (was Re: Category Types)
Date: Wed, 25 Jun 2003 16:15:30 -0400
Message-ID: <LgoKa.528$0k7.70729756_at_mantis.golden.net>
"Paul Vernon" <paul.vernon_at_ukk.ibmm.comm> wrote in message
news:bdcm8b$cvm$1_at_gazette.almaden.ibm.com...
> "Bob Badour" <bbadour_at_golden.net> wrote in message
> news:TtkKa.509$LI6.68898946_at_mantis.golden.net...
> [snip]
> > > >What do you propose for logical independence if not views?
> > >
> > > Alternate, information equivalent, database schemas.
> >
> > And how does this differ from views?
>
> Because to the user of a particular database schema sees as a table, what
a
> user of an alternate schema would see as a view. Giving a user a view and
> telling him it's a table is not good enougth unless the catalog reflects
that
> fact (including showing that any tables that the view is based on are
actually
> views, and acuratly reporting the constaints on the table that used to be
a
> view).
>
> In otherwords, the concept of views does not properly capture the 'schema
> switching' process that should (logically) occur when you want to treat a
set
> of views as tables
I'm not sure the system catalog a casual user sees should even distinguish between base and derived relation variables. However, I don't see how that invalidates views and view updatability.
> [snip]
> > One can present a relation to the dbms that contradicts the predicate
for
> > the database. Nothing prevents one from presenting the contradiction;
the
> > integrity function prevents the contradictory data from corrupting the
> > database.
>
> Agreed.
>
> (I think) my point was meant to be more about the contradictions of
multiple
> assignment. In particular I'm no fan of this sentence from the manifesto
> (page169 2nd Ed):
> "Note that the overall result [of a multiple assignment] might be
> unpredictable if the target variables T1, T2, ..., Tn are not all
distinct"
I think the 'in parallel' part is a bad idea. The compiler should be able to determine which actions can proceed in parallel simply from the DAG it builds for the expression.
> I don't want any possibility of "unpredictable results" in my DBMS (short
of
> explicitly calling non-deterministic functions such as RAND())
I agree. "Unpredictable" basically equates to incomprehensibly complex.
> What does it mean to assign two values to a single variable "in parallel"
as
> the TTM allows with multiple assignment?
The "in parallel" part seems a mistake.
> To me, the thing that is broken is not (particularly) multiple assignment,
but
> view updating. If we did not have view updating, then we could just limit
> multiple assignment to assigning values to relvars just once, but with
view
> updating we have to allow one relvar to be updated twice.
>
> The alternative of banning views as targets in multiple assignment smacks
of a
> hack, so I just go for banning views as targets of assignments at all :-)
I don't think that views cause the problem. I think the parallelism is the problem.
> [snip]
> > > Then what about these macros?
> > >
> > > INSERT INTO A VALUES (1,'A'), (2,'B'),
> > > DELETE FROM B WHERE j = 'B';
> >
> > Macros?
> > Do macros have preconditions?
>
> D&D's do. Well, post-conditions anyway. However they don't define them as
part
> of some macro expansion expression. That would involve a model of
exceptions
> other than plain constraint breakages for one. No, they just give us the
> semantics of say INSERT (page 166), where the cardinality after the insert
> should be that of the before insert plus the number of inserted rows.
>
> Personally I one reason why I would like INSERT to not fail on duplicates
is
> precisely because one could then define such a macro expansion expression
> without worrying about 'duplicate insert exceptions '
I would prefer a system with preconditions and postconditions.
> [snip]
> > We have no way to force every user to read and to fully comprehend the
> > catalog prior to presenting data.
>
> Of course, but if they do fully check their incoming data and update
statement
> against the catalog constraints, then they should be guaranteed that the
> update will work. I.e. none of this view updating stuff where all the
> constraints on the view are not in the catalog.
Why do you think the constraints are not in the catalog? The predicate of the view should appear in the catalog. Is there something I am missing? Received on Wed Jun 25 2003 - 22:15:30 CEST