Referential Integrity And Warehouse Performance Oracle Tips by Burleson September 1, 2015

Referential Integrity And Warehouse Performance

CREATE TABLE CUSTOMER (
cust_id NUMBER
CONSTRAINT cust_ukey UNIQUE (cust_id),
cust_name VARCHAR(30),
cust_address VARCHAR(30);

CREATE TABLE ORDER (
order_id NUMBER,
order_date DATE,
cust_id NUMBER
CONSTRAINT cust_fk REFERENCES CUSTOMER ON DELETE RESTRICT,
);
To ensure that SQL*Plus has no ad-hoc updates, it can be configured to disallow update operations. This is accomplished with the PRODUCT_USER_PROFILE table. Issuing the following row into this table will disable any ad-hoc updates with SQL*Plus:

INSERT INTO PRODUCT_USER_PROFILE (product, user_id, attribute)
VALUES (
‘SQL*Plus’,
‘%’
‘UPDATE’);

Are you now free to write you own procedural RI without fear of accidental corruption? Actually, there is another way that users can access ad-hoc query, thereby bypassing your business rules. A user on a PC (with SQL*Net installed) can access Oracle using ODBC without ever entering SQL*Plus. So beware, and be sure that all ad-hoc holes have been plugged before attempting to write your own RI rules.

Another problem with RI occurs when two tablespaces each contain tables that have foreign key rules into the other tablespace. The DBA must commonly drop and rebuild the tablespaces as a part of routine database compression; for example, when trying to drop a tablespace (say TS1) that has RI into another tablespace, the DROP TABLESPACE CASCADE will fail because foreign key references are contained in table B in tablespace TS2. Conversely, the DBA cannot drop tablespace TS2 because it has references into tablespace TS1. This turns DBA maintenance into a nightmare, since all constraints must be identified and disabled from TS2 in order to drop tablespace TS1.

The

create cluster
   orders_cluster
(