Re: Why no database constraints?

From: Thomas Muller <>
Date: 2000/03/23
Message-ID: <jvpC4.21843$>#1/1

Eric Mortensen <> wrote in message news:8bchpa$n00$
> Hello, I've been thinking about one thing:
> It seems to me that so much business logic could be implemented through
> database constraints spanning multiple tables instead of in stored
> procedures/triggers. Why does none of the major RDBMS servers allow such
> constraints? It doesn't seem to be particularly problematic to implement,
> is it?

In order to keep consistency, an RDBMS enforces a set of integrity constraints. The domain constraint restricts a table field to a certain type and a possible range within that type. Key constraints enforce uniqeness of individual tuples. The referential integrity constraint enforce the absence of dangling tuples, and is a constraint spanning multiple tables by nature. Assertions are predicates imposed on the database in order to at any time satisfy a certain condition. Assertions may span multiple tables.

Higher order constraints which by nature is impossible to express with the database primitive constraints explained above, must be enforced by triggers. A trigger is a statement that is executed automatically by the system as a side effect of a modification to the database. To design a trigger mechanism, one must specify the conditions under which the trigger is to be executed and specify the actions to be taken when the trigger executes.

So you see, triggers are a vital part of the constraint set a RDBMS offers, simply because every thinkable business rule can't be expressed with the more "simple" primitive constructions. In the real world when developing multitiered applications, you're often compelled to enforce business rules in a even higher level than the database(s). As a rule of thumb, you should always try to enforce a business rule at the lowest level possible.


Received on Thu Mar 23 2000 - 00:00:00 CET

Original text of this message