Timeline for Make sure that such a field combination exists in another table when inserting
Current License: CC BY-SA 4.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Sep 26, 2022 at 17:39 | answer | added | Gunther Schadow | timeline score: 2 | |
| Sep 26, 2022 at 16:18 | comment | added | Don Draper |
@ypercubeᵀᴹ, see my edit, please. Do you think this approach looks better? It's a bit hacky too but at least this way the query itself guarantees that we only consider an existing match from table_a to be inserted
|
|
| Sep 26, 2022 at 16:17 | history | edited | Don Draper | CC BY-SA 4.0 |
added 244 characters in body
|
| Sep 26, 2022 at 16:04 | comment | added | ypercubeᵀᴹ | It's denormalization, yes. The other option is to remove user_if from table a_b. You can always get this info with a join. | |
| Sep 26, 2022 at 16:00 | comment | added | Don Draper |
This makes sense, but it feels a bit awkward to create a UNIQUE constraint on (id, user_id) given that id is already unique. Or isn't that a bad practice?
|
|
| Sep 26, 2022 at 15:36 | comment | added | ypercubeᵀᴹ |
If you want any combination of (table_a_id, user_id) you add to table a_b to have a relevant row (id, user_id) in table a then you need to add a FOREIGN KEY like that. CONSTRAINT a_b__ref__a__fk FOREIGN KEY (table_a_id, user_id) REFERENCES a (id, user_id) - and the required UNIQUE constraint on table a
|
|
| Sep 26, 2022 at 15:18 | history | asked | Don Draper | CC BY-SA 4.0 |