Re: Coul constraint *enforcement be done at compile time vs runtime ?

On 16 juin, 16:20, "Walter Mitty" <wami..._at_verizon.net> wrote:
> "Cimode" <cim..._at_hotmail.com> wrote in message
>
> news:d156099b-b43c-47ae-a5be-3dc6cdf85d84_at_e21g2000yqb.googlegroups.com...
>
> > As the subject says...
>
> > The traditional direct image system approach consists of having
> > relations constraints implemented at the time when the relation is
> > updated meaning during UPDATE/DELETE/INSERT operations.  As a part of
> > a research effort to understand better what may be a relational system
> > implementation, I have discovered that it is actually possible to
> > perform constraint enforcement at constraint declaration time.
>
> > Since I have not read anything on the subject, I was wandering and
> > hoping for additional references on that specific aspect. I also woul
> > dlike to know if previous attempts at building such systems have been
> > done in the past.
>
> I don't know whether this applies or not, but you can decide.
>
> In addition to constraints that are checked for compliance  (meaning
> "enforced") at UPDATE/INSERT/DELETE time there is yet another time that a
> SQL DBMS might check constraints.  It's at COMMIT time.  It is possible to
> come up with collections of constraints such that it is impossible to get
> from one legitimate state to another legitimate state without temporarily
> putting the database in a non compliant state.   By deferring some
> constraints to COMMIT time, it becomes possible to  get through the non
> compliant state without being blocked by a constraint enforcement.  I can
> give an example if that helps. A good DBMS will make it possible to defer
> constraint checking when appropriate.
Thank you for this input.

> I am not familiar with Tutorial D.  But some of the previous discussion in
> this newsgroup leads me to believe that the above commentary would not apply
> to Tutorial D.  In particular, the transformations associated with a single
> transaction in SQL can require a series of actions, where each UPDATE,
> INSERT, or DELETE is a separate action.  In Tutorial D, if I understand it
> correctly,  the transformations that need to be considered atomic can all be
> expressed as one action, in such a way that the programmer need never be
> aware of actions and transactions being different units of work.  I am
> hoping that someone who does know D will clarify this point.

> I do not know whether your proposed implementation resmbles SQL or D in this
> regard.  Hope this helps.

Thank you...I have posted a few examples of syntax on this ng and one may see that the language in fact ressembles neither. The language I am developping has some common traits but is inherently different. The two above languages are based on flawed computing models for representing relations and operate these relations. But again we are not in the layer of RM but rather in the layer of computing models to represent RM the way it is supposed to be represented.

Regards... Received on Wed Jun 17 2009 - 14:00:33 CEST