Advanced Database Constraints: Don’t Look for a Second

One of the powers of RDBMS as we use them today are constraints. I use unique indexes, not null constraints and foreign keys on a regular basis and if you do any work with RDBMSs you probably do as well.

From time to time one comes at a point where you think “it would be nice to enforce this with some kind of constraint”, but you can’t. Well maybe you just didn’t try hard enough. This is the second part of the mini series about somewhat special constraints for (Oracle) databases.

Let’s assume you want to model a system of superheroes an villain. Each superhero has an arch_villain and each villain has an arch superhero. Thats simple, isn’t it?

    CREATE TABLE super_hero (
      id number(10),
      name varchar2(200) NOT NULL UNIQUE,
      arch_villain_id number(10) NOT NULL,
      CONSTRAINT super_hero_pk PRIMARY KEY (id)
    );
     
    CREATE TABLE villain   (
      id number(10),
      name varchar2(200) NOT NULL UNIQUE,
      arch_hero_id number(10) NOT NULL,
      CONSTRAINT villain_pk PRIMARY KEY (id)
    );
     
    ALTER TABLE super_hero
    ADD constraint arch_villain_fk
    FOREIGN KEY(arch_villain_id)
    REFERENCES villain(id);
     
    ALTER TABLE villain
    ADD constraint arch_hero_fk
    FOREIGN KEY(arch_hero_id)
    REFERENCES super_hero(id);

Not so fast. Try to insert a row into these tables. It doesn’t work. Before you can insert the first super hero you have to insert a first villain to serve as a arch villain for our super hero. But this arch villain needs a super hero first for use as arch super hero. A vicious circle.

Looks like we have to drop at least one of our constraints. Actually no. We can make it a deferred constraint like so:

    CREATE TABLE super_hero (
      id number(10),
      name varchar2(200) NOT NULL UNIQUE,
      arch_villain_id number(10) NOT NULL,
      CONSTRAINT super_hero_pk PRIMARY KEY (id)
    );
     
    CREATE TABLE villain   (
      id number(10),
      name varchar2(200) NOT NULL UNIQUE,
      arch_hero_id number(10) NOT NULL,
      CONSTRAINT villain_pk PRIMARY KEY (id)
    );
     
    ALTER TABLE super_hero
    ADD constraint arch_villain_fk
    FOREIGN KEY(arch_villain_id)
    REFERENCES villain(id)
    deferrable initially deferred;
     
    ALTER TABLE villain
    ADD constraint arch_hero_fk
    FOREIGN KEY(arch_hero_id)
    REFERENCES super_hero(id)
    deferrable initially deferred;

Now we can enter our data in a pretty natural way:

    INSERT INTO super_hero(id, name, arch_villain_id) VALUES (1, 'Spider-Man', 2);
     
    INSERT INTO villain(id, name, arch_hero_id) VALUES(2, 'Green Goblin', 1);
     
    commit;

What happened? Are the constraints still there? Yes they are:

    INSERT INTO super_hero(id, name, arch_villain_id) VALUES (1, 'Spider-Man', 2);
     
    INSERT INTO villain(id, name, arch_hero_id) VALUES(3, 'Green Goblin', 1);
     
    commit; – fails with ORA-02091: transaction rolled back ORA-02291: integrity constraint (USER_1DA56.ARCH_VILLAIN_FK) violated – parent key not found : commit

But they are only enforced on commit, not after every DML statement like it is done normaly.

Many Java developers know this feature due to a bug in hibernate that causes illegal intermediate inserts/updates. Most database developers know this feature more as a performance tuning tool. When you insert or update millions of rows Oracle has to executes additional statementes in order to verify constraints. This can cost a considerable amount of performance and often can be done much more efficient when one waits until all the data has its final state.