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

"Walter Mitty" <wamitty_at_verizon.net> wrote in message news:uSNZl.1309$P5.511_at_nwrddc02.gnilink.net...
>
> "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.
>

D requires that constraints be checked at the end of each statement, not at the end of each transaction, but D provides support for multiple assignment, in which a series (not a set) of assignments are submitted en mass as a single statement.

> 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:46:00 CEST