Има малък спад в производителността при вмъквания, актуализации и изтривания, защото FK трябва да се провери. За отделен запис това обикновено би било толкова малко, че да бъде незабележимо, освен ако не започнете да имате невероятен брой FK, свързани с масата (Ясно е, че отнема повече време, за да проверите 100 други таблици от 2). Това е нещо добро, а не лошо, тъй като бази данни без целостта са ненадеждни и следователно безполезни. Не трябва да разменяте почтеността за скорост. Този спад в производителността обикновено се компенсира от по-добрата способност за оптимизиране на плановете за изпълнение.
Имаме база данни със среден размер с около 9 милиона записа и FK навсякъде, където трябва да бъдат и рядко забелязваме спад в производителността (освен на една лошо проектирана таблица, която има доста над 100 външни ключа, изтриването на записи от това е малко бавно, както всички трябва да се провери). Почти всеки dba, който познавам, който се занимава с големи, терабайтни бази данни и истинската нужда от висока производителност на големи набори от данни настоява за ограничения на външния ключ, защото целостта е ключът към всяка база данни. Ако хората с бази данни с размер на терабайти могат да си позволят много малкия удар на производителността, тогава можете и вие.
FK не се индексират автоматично и ако не са индексирани, това може да причини проблеми с производителността.
Честно казано, бих взел копие на вашата база данни, бих добавил правилно индексирани FK и ще покажа разликата във времето за вмъкване, изтриване, актуализиране и избор от тези таблици в сравнение със същата от вашата база данни без FK. Покажете, че няма да причините удар в производителността. След това покажете резултатите от заявки, които показват осиротели записи, които вече нямат значение, тъй като PK, с който са свързани, вече не съществува. Особено ефективно е да се покаже това за таблици, които съдържат финансова информация („Имаме 2700 поръчки, които не можем да свържем с клиент“ ще накара ръководството да седне и да обърне внимание).
