Jest mały spadek wydajności przy wstawianiu, aktualizowaniu i usuwaniu, ponieważ trzeba sprawdzić FK. W przypadku pojedynczego rekordu byłoby to zwykle tak niewielkie, że byłoby niezauważalne, chyba że zaczniesz mieć śmieszną liczbę FK związanych z tabelą (oczywiście, sprawdzenie 100 innych tabel zajmuje więcej czasu niż 2). To dobra rzecz, a nie zła, ponieważ bazy danych bez integralności są niewiarygodne, a tym samym bezużyteczne. Nie powinieneś wymieniać uczciwości na szybkość. Ten spadek wydajności jest zwykle równoważony przez lepszą zdolność do optymalizacji planów wykonania.
Mamy średniej wielkości bazę danych z około 9 milionami rekordów i FK wszędzie tam, gdzie powinny i rzadko zauważamy spadek wydajności (z wyjątkiem jednej źle zaprojektowanej tabeli, która ma ponad 100 kluczy obcych, usuwanie rekordów z tego jest trochę powolne, ponieważ wszystkie należy sprawdzić). Prawie każdy znany mi dbający o to, kto ma do czynienia z dużymi bazami danych o rozmiarze terabajtów i prawdziwą potrzebą wysokiej wydajności na dużych zestawach danych, nalega na ograniczenia klucza obcego, ponieważ integralność jest kluczem do każdej bazy danych. Jeśli ludzie z bazami danych o wielkości terabajtów mogą sobie pozwolić na bardzo mały spadek wydajności, to Ty też możesz.
FK nie są automatycznie indeksowane, a jeśli nie są indeksowane, może to powodować problemy z wydajnością.
Szczerze mówiąc, wziąłbym kopię twojej bazy danych, dodałbym odpowiednio zindeksowane FK i pokazałby różnicę czasu do wstawienia, usunięcia, aktualizacji i wybrania z tych tabel w porównaniu z tym samym z twojej bazy danych bez FK. Pokaż, że nie spowodujesz spadku wydajności. Następnie pokaż wyniki zapytań, które pokazują osierocone rekordy, które nie mają już znaczenia, ponieważ PK, z którym są powiązane, już nie istnieje. Szczególnie skuteczne jest pokazanie tego w przypadku tabel zawierających informacje finansowe („Mamy 2700 zamówień, których nie możemy powiązać z klientem” spowoduje, że kierownictwo usiądzie i zwróci uwagę).
