Re: Help with a relationship

"Jan.Hidders" <hidders_at_hcoss.uia.ac.be> wrote in message news:3d80b589$1_at_news.uia.ac.be...
> In article <51d64140.0209110058.715e35a_at_posting.google.com>,
> Paul <pbrazier_at_cosmos-uk.co.uk> wrote:
> >

[snip]

> >What does SQL have a FOREIGN KEY clause when the CHECK clause would
> >suffice?
>
> Next to efficiency it also allows you to state how what should be doen if
> the constraint is violoted, e.g., ON DELETE CASCADE.
>

Maybe to state things slightly differently, a FOREIGN KEY constraint is a DB constraint, but stated and defined in declarative fashion. In other words, it enforces constraints across one or more tables within the database. Today's relational DBMS's, and the SQL data access language, are somewhat limited in their capability in defining any customized database constraint, other than by implementing procedural logic (e.g. triggers).

Thus, declaring a FOREIGN KEY constraint is perhaps preferable that defining a CHECK constraint because one can define and configure it <declaratively> instead of using procedural implementations which are not easily definable within a data definition language. Obviously, this would naturally be applicable to an increase in efficiency and reuse as Jan has already stated.

Regards,

Daniel Guntermann Received on Fri Sep 20 2002 - 21:39:12 CEST