Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!apple!oliveb!amdahl!rtech!squid!robf
From: robf@squid.rtech.com (Robert Fair)
Newsgroups: comp.databases
Subject: Re: Ingres and referential integrities
Keywords: Ingres referential integrities
Message-ID: <3236@rtech.rtech.com>
Date: 27 Jul 89 12:41:50 GMT
References: <3081@rti.UUCP> <3225@rtech.rtech.com> <9677@alice.UUCP>
Sender: news@rtech.rtech.com
Reply-To: robf@squid.UUCP (Robert Fair)
Distribution: comp
Organization: Relational Technology, Inc.
Lines: 32


>From: debra@alice.UUCP (Paul De Bra):
>
>Well, it doesn't look good if RTI's technical support doesn't even know
>what referential integrity means, does it?
>
Actually, I know very well what referential integrity means, and so do
many others at RTI !

The essential point of  referential integrity is that the DBMS does not
allow users to violate the integrity (e.g. by writing an ESQL program).
There are two basic ways to do this (both implemented in the DBMS):

- Passive (rules/triggers). This allows users to do any kind of update,
  with rules being fired when update occurs to perform the associated
  referential checks, cascaded updates etc. Rules are very nice, but
  can be complex to setup and maintain (how about cascaded rules ?
  recursive rules ? etc)

- Active (dbprocedures). This defines one or more well-defined interfaces
  to  update  sets of tables, complete with error checking, transaction
  control etc to enforce referential integrity. Database procedures may
  not be as  transparent/elegent as rules but they provide just as
  much data integrity, and are often easier to set up/manage for
  real applications.
  
The choice between active and passive often depends on personal preference,
neither is a perfect solution for all possible cases.

Robert Fair
Technical Support
Relational Technology