Timeline for Design encouraging FK to non-unique/non-PK
Current License: CC BY-SA 3.0
4 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 5, 2015 at 17:40 | comment | added | TommCatt | A connection request is made by a requester for a target. So you want to make the status unique for each target even across different requesters. What are some examples of status values? Surely, Pending can't be one because it would be reasonable to have several requests in that status at the same time. | |
| Oct 5, 2015 at 6:58 | comment | added | Erik |
I agree that (Target, Status) don't make a good FK, which is why I initially dismissed it in my question. I disagree that (Target, Created) would be a better key. I understand why I can't put a FK on Target, which is what I stated in my question. I agree that ConnectionRequestId is the better key as suggested by @ypercube in the comments, and confirmed by myself in the comments. I've also updated my question to give more reasons why I decided to give (Target, Status) a UNIQUE constraint.
|
|
| Oct 5, 2015 at 6:25 | comment | added | TommCatt | The fields (Target, Status) do not make a good key, for the reason I stated. Instead, (Target, Created) would be a better candidate. Also, You are trying to create a FK from PushSent to Connection request. But this isn't working because you are using the non-unique field Target. You don't want to have the PushSent record refer to the target, but to the connection request. The request refers to the target. So in your FK constraint definition in the PushSent table, change Target to ConnectionRequestId. | |
| Oct 5, 2015 at 5:06 | history | answered | TommCatt | CC BY-SA 3.0 |