Czy klucze obce są naprawdę potrzebne w projekcie bazy danych?

O ile wiem, klucze obce (FK) są używane, aby pomóc programiście w poprawnym manipulowaniu danymi. Załóżmy, że programista faktycznie robi to już we właściwy sposób, czy naprawdę potrzebujemy koncepcji kluczy obcych?

Czy są jakieś inne zastosowania kluczy obcych? Czy coś mi umyka?

Klucze obce pomagają wymusić integralność referencyjną na poziomie danych. Poprawiają również wydajność, ponieważ są zwykle indeksowane domyślnie.

Klucze obce mogą również pomóc programiście napisać mniej kodu przy użyciu takich rzeczy jak ON DELETE CASCADE. Oznacza to, że jeśli masz jedną tabelę zawierającą użytkowników, a drugą zawierającą zamówienia lub coś w tym rodzaju, usunięcie użytkownika może automatycznie usunąć wszystkie zamówienia, które wskazują na tego użytkownika.

Nie wyobrażam sobie projektowania bazy danych bez kluczy obcych. Bez nich ostatecznie popełnisz błąd i zepsujesz integralność swoich danych.

Ściśle mówiąc, nie są wymagane , ale korzyści są ogromne.

Jestem prawie pewien, że FogBugz nie ma ograniczeń klucza obcego w bazie danych. Chciałbym usłyszeć, jak zespół Fog Creek Software konstruuje swój kod, aby zagwarantować, że nigdy nie wprowadzą niespójności.

Schemat bazy danych bez ograniczeń FK jest jak jazda bez pasów bezpieczeństwa.

Pewnego dnia pożałujesz. Nie poświęcanie tej odrobiny dodatkowego czasu na podstawy projektowania i integralność danych to niezawodny sposób na późniejszy ból głowy.

Czy zaakceptowałbyś kod w swojej aplikacji, który był taki niechlujny? To bezpośrednio uzyskiwało dostęp do obiektów członkowskich i bezpośrednio modyfikowało struktury danych.

Jak myślisz, dlaczego stało się to trudne, a nawet niedopuszczalne we współczesnych językach?

Tak.

1. Dzięki nim jesteś uczciwy
2. Dzięki nim nowi deweloperzy są uczciwi
3. Możesz to zrobić ON DELETE CASCADE
4. Pomagają w tworzeniu ładnych diagramów, które same wyjaśniają powiązania między tabelami

Załóżmy, że programista faktycznie robi to już we właściwy sposób

Stawianie takiego przypuszczenia wydaje mi się skrajnie złym pomysłem; generalnie oprogramowanie jest fenomenalnie błędne.

I o to naprawdę chodzi. Deweloperzy nie mogą tego naprawić, więc upewnienie się, że baza danych nie może być wypełniona złymi danymi, jest dobrą rzeczą.

Chociaż w idealnym świecie, sprzężenia naturalne używałyby relacji (tj. Ograniczeń FK) zamiast pasujących nazw kolumn. To uczyniłoby FK jeszcze bardziej użytecznymi.

Osobiście jestem zwolennikiem kluczy obcych, ponieważ formalizuje to relacje między tabelami. Zdaję sobie sprawę, że twoje pytanie zakłada, że ​​programista nie wprowadza danych, które naruszałyby integralność referencyjną, ale widziałem zbyt wiele przypadków naruszenia integralności referencyjnej danych, pomimo najlepszych intencji!

Ograniczenia przed kluczem obcym (zwane również deklaratywną integralnością referencyjną lub DRI) poświęcono dużo czasu na implementację tych relacji przy użyciu wyzwalaczy. Fakt, że możemy sformalizować związek za pomocą deklaratywnego ograniczenia, jest bardzo potężny.

@John - inne bazy danych mogą automatycznie tworzyć indeksy dla kluczy obcych, ale SQL Server tego nie robi. W SQL Server relacje klucza obcego są tylko ograniczeniami. Musisz osobno zdefiniować swój indeks kluczy obcych (co może być korzystne).

Edycja: Chciałbym dodać, że IMO użycie kluczy obcych do obsługi ON DELETE lub ON UPDATE CASCADE niekoniecznie jest dobrą rzeczą. W praktyce odkryłem, że kaskadowe usuwanie powinno być uważnie rozważane w oparciu o związek danych - np. Czy masz naturalnego rodzica-dziecko, gdzie może to być w porządku, czy też powiązana tabela jest zbiorem wartości wyszukiwania. Korzystanie z aktualizacji kaskadowych oznacza, że ​​zezwalasz na modyfikację klucza podstawowego jednej tabeli. W takim razie mam ogólną filozoficzną niezgodę, że klucz podstawowy tabeli nie powinien się zmieniać. Klucze powinny być z natury stałe.

Jak bez klucza obcego można stwierdzić, że dwa rekordy w różnych tabelach są powiązane?

Myślę, że chodzi o integralność referencyjną, gdzie nie można utworzyć rekordu podrzędnego bez istniejącego rekordu nadrzędnego itp. Są one często nazywane ograniczeniami klucza obcego - ale nie należy ich mylić z istnieniem kluczy obcych w pierwsze miejsce.

Czy jest korzyść z braku kluczy obcych? O ile nie używasz kiepskiej bazy danych, konfiguracja FK nie jest taka trudna. Dlaczego więc mielibyście ich unikać? Jedną rzeczą jest mieć konwencję nazewnictwa, która mówi, że kolumna odwołuje się do innej, a inną jest wiedzieć, że baza danych faktycznie weryfikuje tę relację za Ciebie.

Przypuszczam, że mówisz o ograniczeniach klucza obcego wymuszanych przez bazę danych . Prawdopodobnie używasz już kluczy obcych, po prostu nie poinformowałeś o tym bazy danych.

Załóżmy, że programista faktycznie robi to już we właściwy sposób, czy naprawdę potrzebujemy koncepcji kluczy obcych?

Teoretycznie nie. Jednak nigdy nie było oprogramowania bez błędów.

Błędy w kodzie aplikacji zwykle nie są tak niebezpieczne - identyfikujesz błąd i naprawiasz go, a następnie aplikacja znów działa płynnie. Ale jeśli błąd pozwala na wejście do bazy danych uszkodzonych danych, utkniesz z tym! Bardzo trudno jest odzyskać uszkodzone dane w bazie danych.

Zastanów się, czy subtelny błąd w FogBugz pozwolił na zapisanie uszkodzonego klucza obcego w bazie danych. Naprawienie błędu i szybkie rozesłanie poprawki do klientów w wydaniu poprawiającym błędy może być łatwe. Jak jednak naprawić uszkodzone dane w dziesiątkach baz danych? Prawidłowy kod może teraz nagle się zepsuć, ponieważ założenia dotyczące integralności kluczy obcych nie są już aktualne.

W aplikacjach internetowych zazwyczaj tylko jeden program komunikuje się z bazą danych, więc jest tylko jedno miejsce, w którym błędy mogą uszkodzić dane. W aplikacji korporacyjnej może istnieć kilka niezależnych aplikacji komunikujących się z tą samą bazą danych (nie wspominając o osobach pracujących bezpośrednio z powłoką bazy danych). Nie ma sposobu, aby mieć pewność, że wszystkie aplikacje działają zgodnie z tymi samymi założeniami bez błędów, zawsze i na zawsze.

Jeśli ograniczenia są zakodowane w bazie danych, najgorsze, co może się zdarzyć z błędami, jest to, że użytkownikowi wyświetla się brzydki komunikat o błędzie dotyczący niespełnienia jakiegoś ograniczenia SQL . Jest to o wiele lepsze niż wpuszczanie uszkodzonych danych do bazy danych przedsiębiorstwa, gdzie z kolei zepsuje wszystkie aplikacje lub po prostu doprowadzi do wszelkiego rodzaju błędnych lub wprowadzających w błąd danych wyjściowych.

Aha, a ograniczenia klucza obcego również poprawiają wydajność, ponieważ są domyślnie indeksowane. Nie przychodzi mi do głowy żaden powód, by nie używać ograniczeń klucza obcego.

FK są bardzo ważne i zawsze powinny istnieć w Twoim schemacie, chyba że jesteś na eBayu .

Myślę, że niektóre pojedyncze rzeczą w pewnym momencie musi być odpowiedzialny za zapewnienie prawidłowych relacji.

Na przykład Ruby on Rails nie używa kluczy obcych, ale sam sprawdza poprawność wszystkich relacji. Jeśli kiedykolwiek korzystasz z bazy danych tylko z tej aplikacji Ruby on Rails, to jest w porządku.

Jeśli jednak masz innych klientów, którzy piszą do bazy danych, to bez kluczy obcych muszą zaimplementować własną walidację. Następnie masz dwie kopie kodu walidacyjnego, które najprawdopodobniej są różne, co każdy programista powinien być w stanie powiedzieć, że jest to grzech główny.

W tym momencie klucze obce są naprawdę potrzebne, ponieważ pozwalają ponownie przenieść odpowiedzialność do jednego punktu.

Klucze obce pozwalają osobie, która nie widziała wcześniej Twojej bazy danych, na określenie relacji między tabelami.

Teraz wszystko może być dobrze, ale zastanów się, co się stanie, gdy twój programista odejdzie i ktoś inny będzie musiał przejąć kontrolę.

Klucze obce pozwolą im zrozumieć strukturę bazy danych bez przeszukiwania tysięcy linii kodu.

O ile mi wiadomo, klucze obce są używane do pomocy programiście w poprawnym manipulowaniu danymi.

Obroty umożliwiają administratorowi DBA ochronę integralności danych przed grzebaniem użytkowników, gdy programista tego nie robi, a czasami chronią przed błędami programistów.

Załóżmy, że programista faktycznie robi to już we właściwy sposób, czy naprawdę potrzebujemy koncepcji kluczy obcych?

Programiści są śmiertelni i omylni. FK są deklaratywne, co sprawia, że ​​trudniej je schrzanić .

Czy są jakieś inne zastosowania kluczy obcych? Czy coś mi umyka?

Chociaż nie po to zostały stworzone, FK zapewniają solidne i niezawodne wskazówki dotyczące narzędzi do tworzenia diagramów i konstruktorów zapytań. Jest to przekazywane użytkownikom końcowym, którzy desperacko potrzebują silnych i wiarygodnych wskazówek.

Nie są one bezwzględnie konieczne, ponieważ pasy bezpieczeństwa nie są bezwzględnie konieczne. Ale naprawdę mogą cię uchronić przed zrobieniem czegoś głupiego, który zepsuje twoją bazę danych.

O wiele przyjemniej jest debugować błąd ograniczenia FK, niż rekonstruować usunięcie, które zepsuło aplikację.

Są ważne, ponieważ aplikacja nie jest jedynym sposobem, w jaki można manipulować danymi w bazie danych. Twoja aplikacja może obsługiwać referencyjną integralność tak uczciwie, jak chce, ale wystarczy jeden bozo z odpowiednimi uprawnieniami, aby pojawić się i wydać polecenie wstawiania, usuwania lub aktualizowania na poziomie bazy danych, a wymuszanie integralności referencyjnej aplikacji jest pomijane. Wstawienie ograniczeń FK na poziomie bazy danych oznacza, że ​​wykluczając, aby ten bozo zdecydował się wyłączyć ograniczenie FK przed wydaniem polecenia, ograniczenie FK spowoduje niepowodzenie instrukcji wstawiania / aktualizacji / usuwania z błędem i naruszenie integralności referencyjnej.

Myślę o tym w kategoriach kosztów / korzyści ... W MySQL dodanie ograniczenia to pojedyncza dodatkowa linia DDL . To tylko kilka kluczowych słów i kilka sekund namysłu. To jedyny „koszt” moim zdaniem ...

Narzędzia uwielbiają klucze obce. Klucze obce zapobiegają złym danym (czyli osieroconym wierszom), które mogą nie wpływać na logikę biznesową lub funkcjonalność, a zatem pozostają niezauważone i gromadzą się. Uniemożliwia również programistom, którzy nie znają schematu, wdrażanie całych fragmentów pracy bez zdawania sobie sprawy, że brakuje im relacji. Być może wszystko jest świetne w zakresie twojej obecnej aplikacji, ale jeśli coś przeoczyłeś i któregoś dnia zostanie dodane coś nieoczekiwanego (pomyśl o fantazyjnych raportach), możesz znaleźć się w miejscu, w którym będziesz musiał ręcznie wyczyścić złe dane, które gromadziły się od początku schematu bez sprawdzania wymuszonego przez bazę danych.

Krótki czas potrzebny na skodyfikowanie tego, co już masz w głowie, kiedy układasz rzeczy razem, może zaoszczędzić tobie lub komuś innemu kilka miesięcy lub lat smutku w przyszłości.

Pytanie:

Czy są jakieś inne zastosowania kluczy obcych? Czy coś mi umyka?

Jest trochę załadowany. Wstaw komentarze, wcięcia lub nazewnictwo zmiennych w miejsce „kluczy obcych”… Jeśli już doskonale rozumiesz przedmiot, o którym mowa, to „na nic się to nie zda”.

Redukcja entropii. Zmniejsz możliwość wystąpienia chaotycznych scenariuszy w bazie danych. Mamy trudności, ponieważ rozważa wszystkie możliwe możliwości, więc moim zdaniem redukcja entropii jest kluczem do utrzymania każdego systemu.

Kiedy zakładamy na przykład: każde zamówienie ma klienta, to założenie powinno być przez coś egzekwowane . W bazach danych tym „czymś” są klucze obce.

Myślę, że jest to warte kompromisu w szybkości rozwoju. Jasne, możesz kodować szybciej, gdy są wyłączone i prawdopodobnie dlatego niektórzy ich nie używają. Osobiście zabiłem kilka godzin z NHibernate i pewnym ograniczeniem klucza obcego, które denerwuje się, gdy wykonuję jakąś operację. JEDNAK wiem, na czym polega problem, więc jest to mniejszy problem. Używam zwykłych narzędzi i są zasoby, które mogą mi pomóc w obejściu tego problemu, być może nawet ludzie, którzy mogą pomóc!

Alternatywą jest umożliwienie błędowi wkradnięcia się do systemu (i przy wystarczającej ilości czasu), gdy klucz obcy nie jest ustawiony, a dane stają się niespójne. Następnie otrzymasz nietypowy raport o błędzie, zbadaj sprawę i „OH”. Baza danych jest skręcona. Jak długo to zajmie naprawa?

Możesz postrzegać klucze obce jako ograniczenie, które:

• Pomóż zachować integralność danych
• Pokaż, w jaki sposób dane są ze sobą powiązane (co może pomóc w egzekwowaniu logiki biznesowej i reguł)
• Jeśli jest używany prawidłowo, może pomóc zwiększyć wydajność, z jaką dane są pobierane z tabel.

Obecnie nie używamy kluczy obcych. I przeważnie tego nie żałujemy.

To powiedziawszy - prawdopodobnie zaczniemy ich używać znacznie częściej w najbliższej przyszłości z kilku powodów, z których oba z podobnych powodów:

1. Tworzenie diagramów. O wiele łatwiej jest stworzyć diagram bazy danych, jeśli istnieją poprawnie używane relacje kluczy obcych.

2. Wsparcie narzędziowe. O wiele łatwiej jest budować modele danych przy użyciu programu Visual Studio 2008 , których można używać dla LINQ to SQL, jeśli istnieją odpowiednie relacje kluczy obcych.

Myślę, że chodzi mi o to, że odkryliśmy, że jeśli wykonujemy dużo ręcznej pracy SQL (konstruowanie zapytania, uruchamianie zapytania, blahablahblah), klucze obce niekoniecznie są niezbędne. Jednak gdy zaczniesz korzystać z narzędzi, stają się one znacznie bardziej przydatne.

Najlepszą rzeczą w ograniczeniach klucza obcego (i ogólnie ograniczeniach tak naprawdę) jest to, że możesz na nich polegać podczas pisania zapytań. Wiele zapytań może stać się znacznie bardziej skomplikowanych, jeśli nie można polegać na modelu danych, który zawiera wartość „prawda”.

W kodzie generalnie gdzieś wyrzucany jest wyjątek, ale w SQL generalnie otrzymujemy po prostu „złe” odpowiedzi.

Teoretycznie SQL Server mógłby używać ograniczeń jako części planu kwerend - ale poza ograniczeniami sprawdzania partycjonowania nie mogę powiedzieć, że kiedykolwiek byłem tego świadkiem.

Klucze obce nigdy nie były jednoznacznie (tabela (kolumna) REFERENCJE KLUCZA OBCEGO) deklarowane w projektach (aplikacje biznesowe i serwisy społecznościowe), nad którymi pracowałem.

Ale zawsze istniała konwencja nazewnictwa kolumn, które były kluczami obcymi.

To jak z normalizacją baz danych - musisz wiedzieć, co robisz i jakie są tego konsekwencje (głównie wydajność).

Zdaję sobie sprawę z zalet kluczy obcych (integralność danych, indeks dla kolumny klucza obcego, narzędzia świadome schematu bazy danych), ale obawiam się również używania kluczy obcych w zasadzie.

Ponadto różne silniki baz danych mogą obsługiwać klucze obce w inny sposób, co może prowadzić do drobnych błędów podczas migracji.

Usunięcie wszystkich zamówień i faktur usuniętego klienta za pomocą ON DELETE CASCADE jest doskonałym przykładem ładnie wyglądającego, ale źle zaprojektowanego schematu bazy danych.

Tak. ON DELETE [RESTRICT | CASCADE] chroni programistów przed wyrzucaniem danych, utrzymując je w czystości. Niedawno dołączyłem do zespołu programistów Rails, którzy nie skupiali się na ograniczeniach baz danych, takich jak klucze obce.

Na szczęście znalazłem takie: http://www.redhillonrails.org/foreign_key_associations.html - Wtyczki RedHill on Ruby on Rails generują klucze obce używając konwencji zamiast stylu konfiguracji . Migracja z product_id spowoduje utworzenie klucza obcego do identyfikatora w tabeli produktów .

Sprawdź inne świetne wtyczki w RedHill , w tym migracje opakowane w transakcje.

Jeśli planujesz wygenerować kod dostępu do danych, tj. Entity Framework lub inny ORM, całkowicie tracisz możliwość generowania modelu hierarchicznego bez kluczy obcych