Question

I was hoping someone could tell me if this would be bad database design:

Let’s say I have two tables:

Person  
Contract

And let’s say I get two types of contracts, a single contract (which involves only one person) and a joint contract (which involves two people). There are no other permutations.

It would be the simplest to set up the Contract table with two FK fields, one of which is nullable, i.e.:

Contract:

ContractID     Description               PersonID      PersonID_Second
1              Single person contract    1112          NULL
2              Joint contract            1073          900

Is this a bad idea?

Thanks
Karl

Answer 1

Two more cents: Are the relationships between the two Persons and the Contract equivalent? Is there a “first” person and a “second along for the ride” person, or do they both share equal importance with regards to this contract? And is the distinction between one-person and two-person (and possible future N-person) contracts an important attribute of the contract?

• If relationships are equivalent, then go with Mitch’s many-to-many solution.
• If there is an important distinction between first and second, Parched Squid’s [saying that that made my morning better!] multiple FK fix would work well.
• But if you forsee N-person contracts, stick with the many-to-many, with an extra attribute in the relationship table indicating “which” relationship is being designated.
• And if you need to sort through your contracts to find or sort by the 1, 2, or N-person ones, it might be more convenient to have an extra attribute indicating type of contract, rather than implementing lots of joins and null-checking logic to count each contract’s related persons.