Czy miałoby to kiedykolwiek sens, aby aplikacja wymuszała integralność bazy danych zamiast posiadania kluczy obcych, ograniczeń sprawdzania itp.?
Jakiego wzrostu wydajności można oczekiwać od niewymuszania integralności bazy danych za pomocą wewnętrznych narzędzi bazy danych?
Odpowiedzi:
Prawdę mówiąc, nie tylko nie zobaczysz dużej utraty wydajności z powodu ograniczeń klucza obcego w bazie danych, ale zobaczysz ulepszenia wydajności. Optymalizator zapytań SQL Server opiera się na koncepcji kluczy głównych i kluczy foriegn, a także innych rodzajów ograniczeń danych. Jeśli są na miejscu i są egzekwowane, optymalizator może je wykorzystać, aby uzyskać lepszą wydajność. Oto post na blogu z prostym przykładem, który pokazuje go w akcji.
Jeśli znajdujesz się w skrajnym przypadku, w którym naprawdę masz więcej wstawek niż odczytów (a aktualizacje i usuwanie wymagają odczytów, więc zwykle kończą się one dodawaniem do liczby odczytów), może być sensowne usunięcie ograniczeń danych dla wydajności, być może . Ale ponieważ przeważająca większość baz danych jest zorientowana na odczyt, poświęcasz wydajność, a nie ją poprawiasz.
I żadna z tych informacji nie wspomina o tym, że integralność danych jest lepiej obsługiwana w bazie danych, ponieważ trzeba ją utworzyć tylko raz, gdy wykonując całą pracę w kodzie, może być konieczne wielokrotne wykonanie tej czynności dla wielu aplikacji (chyba że zaprojektujesz twoją warstwę dostępu do danych i wymagaj od każdej aplikacji dostępu do bazy danych, aby przejść przez tę samą warstwę).
Jeśli używasz systemu relacyjnej bazy danych, powiem, dlaczego tak naprawdę go nie używać. Jeśli nie potrzebujesz danych relacyjnych, skorzystaj z Hadoop lub czegoś innego.
Tak myśli wielu programistów aplikacji.
Kiedy masz ochotę przekazać integralność danych do kodu aplikacji, pomyśl: „Każdy programista i każda aplikacja, która trafia do tej bazy danych od teraz do końca czasu, musi ją doskonale za każdym razem”.
Jakie są szanse?
Nawet jeśli występuje jakikolwiek wzrost wydajności, jest on nieistotny w porównaniu do zwrotu integralności referencyjnej i ogólnej integralności danych.
Dawno minęły czasy, kiedy baza danych jest głupim magazynem danych. Wykorzystaj moc oferowaną przez RDBMS.
Wzrost wydajności to nie wszystko, szczególnie na tak małą skalę jak ta. Ale gdy dowiesz się, że istnieje domniemana relacja klucza obcego, którą twoja aplikacja ma egzekwować, i okazuje się, że nie jest to klucz podstawowy w tabeli odwołań, wtedy nie będziesz bardzo zainteresowany wzrostem wydajności (jeśli w ogóle, mogę nie mów o szczegółach tego).
Powszechną praktyką jest usuwanie ograniczeń (klucze obce, SPRAWDŹ itp.) I indeksów, jeśli wykonujesz wystarczająco duże ładowanie danych, a następnie ponownie włącz / implementuj ograniczenia i indeksy. Ta walidacja ma koszt czasu. Zakłada się, że nie można użyć składni masowego ładowania specyficznej dla bazy danych (w tym minimalizacji rejestrowania).
Nie można powiedzieć, jakiego wzrostu wydajności można się spodziewać - każda sytuacja jest wyjątkowa (typy danych, projekt itp.). Jedynym sposobem na prawdziwą wiedzę jest przetestowanie.
Kilka razy przeszkadzają ograniczenia:
Kiedy trzeba użyć dziedziczenia pojedynczej tabeli (STI). Wyobraź sobie, że sprzedajesz zarówno osobom fizycznym, jak i organizacjom. Będziesz potrzebować pojedynczej tabeli „Party”, której wierszem jest osoba lub organizacja. STI oznacza, że potrzebujesz kilku zerowalnych pól, które nie powinny mieć wartości zerowej. Dziedziczenie tabeli klas rozwiązuje ten problem, ale jest to trudniejsze w przypadku niektórych ORM. Na przykład ActiveRecord Ruby obsługuje tylko STI.
Gdy potrzebujesz obsługiwać wersje robocze encji, może to nie być całkowicie poprawne. Możesz przechowywać wersję roboczą jako json, ale wtedy trudniej jest ponownie użyć tego samego identyfikatora na kliencie - wyobraź sobie, że została zapisana z id = 5, edytowana jako nieprawidłowa i automatycznie zapisana jako draftid = 99. W takim przypadku wszystkie twoje pola prawdopodobnie musiałyby mieć wartość zerową.