This is mostly a design question:
Ok, so I’m trying to create a relationship for a ticket type table that contains a type and a subtype. Each subtype is unique to it’s parent type. I’m trying to avoid having both fields in the ticket table. I’m thinking of just creating a link table with a natural key and then just placing that key in the ticket table, and that key will point to the appropriate combination of Type and Subtype.
My concern is keeping those combinations unique. So for instance, if someone jumps into the table (without doing their homework first) and attempts to add a combination like Type 5, subtype 3, and that particular combination already exists, the dbms shouldn’t allow it, similar to a primary key.
So I’m wondering if it would be stupid (because it feels like it is) to create a primary key that uses the natural key, the type id, and the subtype id. It seems like that wouldn’t help anything because the natural key would end up making every entry unique, thus making every entry valid.
Is there a better way to do this? Would it be simpler to just not attempt to constrain those links/combinations? Should I just place both fields in the ticket table and suck it up?
Use a UNIQUE constraint to ensure that the combination of type and subtype is unique, then have a separate primary key for your natural key.