jakie są zalety definiowania klucza obcego?

Question

Jakie są zalety definiowania klucza obcego podczas pracy z ramką MVC, która obsługuje relację?

Używam relacyjnej bazy danych z ramą, która umożliwia definicje modeli z relacjami. Ponieważ klucze obce są definiowane przez modele, wydaje się, że klucze obce są zbędne. Jeśli chodzi o zarządzanie bazą danych aplikacji w fazie rozwoju, edycja/usuwanie tabel za pomocą kluczy obcych jest kłopotliwe.

Czy jest jakaś korzyść z używania kluczy obcych, z których korzystam, rezygnując z ich używania w ogóle?

Answer 1

Klucze obce z ograniczeniami (w niektórych silnikach baz danych) zapewniają integralność danych na niskim poziomie (poziom bazy danych). Oznacza to, że nie można fizycznie utworzyć rekordu, który nie spełnia relacji. To tylko sposób na bycie bezpieczniejszym.

Answer 2

Daje to integralność danych wymuszoną na poziomie bazy danych. Pomaga to uniknąć błędów w logice aplikacji, które mogą powodować nieprawidłowe dane.

Jeśli jakiekolwiek operacje na danych są wykonywane bezpośrednio w SQL, który pomija logikę aplikacji, chroni również przed błędnymi danymi, które przerywają te ograniczenia.

Dodatkową korzyścią uboczną jest to, że pozwala narzędziom automatycznie generować diagramy bazy danych ze związkami wywodzącymi się z samego schematu. Teoretycznie całe tworzenie diagramów powinno się odbywać przed utworzeniem bazy danych, ale ponieważ baza danych ewoluuje poza początkowe wcielenie, często nie są one aktualizowane, a możliwość generowania diagramu z istniejącej bazy danych jest pomocna zarówno dla przegląd, a także wyjaśnienie struktury nowym programistom dołączającym do projektu.

Pomocne może być wyłączenie FK, gdy struktura bazy danych wciąż się zmienia, ale są one dobrym zabezpieczeniem, gdy schemat jest bardziej ustabilizowany.

Answer 3

Klucz obcy gwarantuje, że istnieje odpowiedni rekord w tabeli zagranicznej. Wyobraź sobie tabelę o nazwie Books, która ma ograniczenie FK na tabeli o nazwie Authors. Każda książka ma gwarancję posiadania Author.

Teraz można zrobić kwerendę, takich jak:

SELECT B.Title, A.Name FROM Books B 
INNER JOIN Authors A ON B.AuthorId = A.AuthorId; 

bez ograniczeń FK, brakujący Author wiersz spowodowałoby całą Book wiersz należy spadła, powodując brakuje książek w swoim zbiorze.

Ponadto, w przypadku ograniczenia FK próba usunięcia autora, do którego wystąpiła co najmniej jedna książka, spowoduje błąd, a nie uszkodzenie bazy danych.

Answer 4

Główne zalety to integralność danych i usuwanie kaskadowe. Możesz także uzyskać przyrost wydajności, gdy zostaną zdefiniowane, a te pola zostaną poprawnie zindeksowane. Na przykład nie można utworzyć numeru telefonu, który nie należy do kontaktu, ani usunąć kontaktu, który można ustawić, aby automatycznie usuwał wszystkie numery telefonów. Tak, możesz utworzyć te połączenia w swoim interfejsie lub w warstwie środkowej, ale nadal będziesz sierotami, jeśli ktoś uruchomi aktualizację bezpośrednio na serwerze przy użyciu SQL zamiast interfejsu użytkownika. Część "kłopot" zmusza Cię do rozważenia tych połączeń przed dokonaniem masowej zmiany. FK uratowały mi boczek wiele razy.

Answer 5

Podczas gdy mogą one być uciążliwe podczas manipulowania danymi rozwoju/testu, zaoszczędzili mi wiele kłopotów związanych z produkcją.

Pomyśl o nich jako o sposobie zachowania integralności danych, zwłaszcza jako zabezpieczenia przed osieroconymi zapisami.

Na przykład, jeśli miał bazę danych odnoszącą wiele PhoneNumber zapisy do Person, co dzieje się z PhoneNumber zapisów gdy rekord Person zostanie usunięty z jakiegokolwiek powodu? Będą one nadal znajdować się w bazie danych, ale identyfikator Person, którego dotyczą, nie będzie już istnieć w odpowiedniej tabeli Person, a użytkownik ma osierocone rekordy.

Tak, można napisać spust, aby usunąć PhoneNumber ilekroć Person zostaje usunięty, ale może to bałagan jeśli przypadkowo usunąć Person i trzeba wycofać.

Tak, być może pamiętasz ręczne pozbywanie się rekordów PhoneNumber, ale co z innymi programistami lub metodami, które piszesz przez 9 miesięcy?

Tworząc klucz obcy, który zapewnia, że ​​każdy PhoneNumber jest powiązany z istniejącym Person, obaj ubezpieczycie się przed zniszczeniem tej relacji, a także dodają "wskazówki" co do zamierzonej struktury danych.