Ref. Integrity: Restricted/cascaded DELETE

From: Janet Traub <trau2349_at_hgc.edu>
Date: Mon, 14 Nov 1994 09:32:57 GMT
Message-ID: <1994Nov14.093257.23551_at_merlin.hgc.edu>


Hello folks, I could use some Ref. integrity advice.

I want to set up a ref. integrity rule at the database level for a particular parent key that is a foreign key to 15 other tables.

My business rule is:

  Allow either a restricted delete or cascaded delete depending on the type   of user accessing the database. If the user is an "administrator" set   ON DELETE CASCADE. For all other users, set restricted delete   (i.e. only allow deletion if none of the 15 tables contains a   dependent child row).

My question:

What is the best way define this fexibilty? Should I create 2 named constraints in each of the 15 tables, such as:

  CREATE TABLE matter_status (
.
.

  CONSTRAINT fk_matter_no FOREIGN KEY matter_no REFERENCES matter_info,   CONSTRAINT fk2_matter_no FOREIGN KEY matter_no REFERENCES

                                         matter_info ON DELETE CASCADE);

and then create a Stored procedure (or trigger) that checks to see if the user is an Admin. and if so, DISABLEs the restricted constraint for each of the 15 tables and ENABLEs the cascaded constraint for each table?

CREATE TRIGGER delete_matter (user_type IN VARCHAR2) BEFORE DELETE ON matter_info
BEFORE
  if user_type is 'ADM' then
  ALTER TABLE matter_contact DISABLE fk_...   ALTER TABLE matter_status DISABLE fk_...
.
.

  ALTER TABLE matter_contact ENABLE fk2_..   ALTER TABLE matter_status ENABLE fk2_..
.
.

END Something tells me there's probably a simpler way. This is my first time defining ref. integrity in Oracle 7. I am also new to using stored procedures and triggers. All advice is MOST appreciated.

-- 
------------------------------------------------------------------------
 Janet Traub                              The Hartford Graduate Center
 trau2349_at_hgc.edu                                         Hartford, CT
------------------------------------------------------------------------
Received on Mon Nov 14 1994 - 10:32:57 CET

Original text of this message