Der er et lille præstationshit på indsættelser, opdateringer og sletninger, fordi FK'en skal kontrolleres. For en individuel post vil dette normalt være så lille, at det ikke kan bemærkes, medmindre du begynder at have et latterligt antal FK'er knyttet til bordet (det tager klart længere tid at kontrollere 100 andre tabeller end 2). Dette er en god ting, ikke en dårlig ting, da databaser uden integritet er utroværdige og dermed ubrugelige. Du bør ikke bytte integritet for hastighed. Dette præstationshit opvejes normalt af den bedre evne til at optimere eksekveringsplaner.
Vi har en mellemstor database med omkring 9 millioner poster og FK'er overalt, hvor de burde være og bemærker sjældent et præstationshit (undtagen på en dårligt designet tabel, der har langt over 100 fremmednøgler, er det lidt langsomt at slette poster fra dette som alt skal kontrolleres). Næsten hver eneste dba, jeg kender, som beskæftiger sig med store databaser i terabyte-størrelse og et sandt behov for høj ydeevne på store datasæt, insisterer på begrænsninger for fremmednøgle, fordi integritet er nøglen til enhver database. Hvis folk med terabyte-store databaser har råd til det meget lille præstationshit, så kan du også.
FK'er indekseres ikke automatisk, og hvis de ikke indekseres, kan dette forårsage ydeevneproblemer.
Helt ærligt, jeg ville tage en kopi af din database, tilføje korrekt indekserede FK'er og vise tidsforskellen for at indsætte, slette, opdatere og vælge fra disse tabeller i sammenligning med det samme fra din database uden FK'erne. Vis, at du ikke vil forårsage et præstationshit. Vis derefter resultaterne af forespørgsler, der viser forældreløse poster, der ikke længere har betydning, fordi den PK, de er relateret til, ikke længere eksisterer. Det er især effektivt at vise dette for tabeller, der indeholder finansiel information ("Vi har 2700 ordrer, som vi ikke kan knytte til en kunde" vil få ledelsen til at sidde op og mærke efter).