I EF Code First er den generelle grund til, at du vil modellere et udenlandsk nøgleforhold, for navigerbarheden mellem enheder. Overvej et simpelt scenario med Country og City , med ivrig indlæsning defineret for følgende LINQ-sætning:
var someQuery =
db.Countries
.Include(co => co.City)
.Where(co => co.Name == "Japan")
.Select(...);
Dette ville resultere i en forespørgsel i stil med:
SELECT *
FROM Country co
INNER JOIN City ci
ON ci.CountryId = co.ID
WHERE co.Name = 'Japan';
Uden et indeks på fremmednøglen på City.CountryId , skal SQL scanne tabellen Byer for at filtrere byerne for landet under en JOIN.
FK-indekset vil også have performancefordele, hvis rækker slettes
fra den overordnede lande-tabell, da referenceintegritet skal registrere tilstedeværelsen af eventuelle sammenkædede byrækker (om FK har ON CASCADE DELETE defineret eller ej).
TL;DR
Indekser på udenlandske nøgler er anbefales , selvom du ikke filtrerer direkte på fremmednøglen, vil den stadig være nødvendig i Joins. Undtagelserne fra dette ser ud til at være ret konstruerede:
-
Hvis fremmednøglens selektivitet er meget lav, f.eks. i ovenstående scenarie, hvis 50 % af ALLE byer i landetabellen var i Japan, ville indekset ikke være nyttigt.
-
Hvis du faktisk aldrig navigerer på tværs af forholdet.
-
Hvis du aldrig sletter rækker fra den overordnede tabel (eller forsøger at opdatere på PK'en) .
En yderligere optimeringsovervejelse er, om den fremmede nøgle skal bruges i Clustered Index af den underordnede tabel (dvs. klynge byer efter land). Dette er ofte fordelagtigt i forhold til overordnede :underordnede tabelrelationer, hvor det er almindeligt sted at hente alle underordnede rækker for forælderen samtidigt.