Question

I have a data table with a primary key called OptDefID. When a record in this table is deleted I need to go and delete all records from the Permissions table that have that OptDefID in the defID field (in Permissions). The tricky part for me is that the Permissions table does not have a primary key and holds lots of different kinds of permissions, and has a permissiontype field. I need to delete rows that have the OptDefID AND a permissiontype of OptDef.

Because I need to consider the permissiontype, I don’t believe a Foreign Key Constraint is appropriate here (or is it?).

I’ve also considered creating a trigger, but am unsure how to get the OptDefID passed into the trigger.

I can do this via the application itself, but I feel like this should be a database level solution.

What’s the best solution?

Answer 1

Say I want to delete from Permissions where defID is 20 and permissiontype is ‘OptDef’. There may be another row in Permissions that has a defID of 20, but has a permissiontype of ‘Member’. That show should not be deleted because it pertains to Members and not Opt data.

Storing table names in fields prevents foreign keys from working properly, as you have discovered.

I recommend you fix the root problem and separate these two foreign keys, so each of them can be individually enforced. For example:

CREATE TABLE Permissions (
    ...
    OptDefId int,
    MemberId int,
    FOREIGN KEY (OptDefId) REFERENCES OptDef ON DELETE CASCADE,
    FOREIGN KEY (MemberId) REFERENCES Members ON DELETE CASCADE,
    CHECK (
        (OptDefId IS NOT NULL AND MemberId IS NULL)
        OR (OptDefId IS NULL AND MemberId IS NOT NULL)
    )
)

The CHECK makes sure only one of the FKs is non-NULL and only non-NULL FKs are enforced.

Alternatively, you could avoid changing your current design and enforce this “special” FK through a trigger, but declarative constraints should be preferred to triggers when possible – declarative constraints tend to leave less room for error and be more “self-documenting”.