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

"Cimode" <cimode_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.

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. Received on Tue Jun 16 2009 - 16:20:10 CEST