Timeline for Performance impact of NOT using a foreign key (many dedicated 1:many key-key tables vs non-fk generic key-key table)
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 26, 2015 at 21:25 | vote | accept | oucil | ||
| Oct 26, 2015 at 12:32 | comment | added | Walter Mitty | Different RDBMS products differ wildly in the cost of checking for orphaned references when something is deleted. Don't use the results obtained with one product to predict the behavior of other products. | |
| Oct 26, 2015 at 11:00 | comment | added | ypercubeᵀᴹ | "There is no performance impact of not using a foreign key." Is this claim a general one or is referring to MySQL only? | |
| Oct 26, 2015 at 3:24 | comment | added | oucil | The type column allows for the composite index and is purely for efficiency, without it, the entire table would be scanned for any linked records, and I wouldn't be able to tell without a second join if that link was the right object type or not. With the type as the first part of the composite index, I can filter first by object type without the need of a second join. Good to know I'm not crazy and this approach has real world application though, thanks. | |
| Oct 25, 2015 at 23:28 | history | answered | Ɖiamond ǤeezeƦ | CC BY-SA 3.0 |