Ile złączeń jest wykonalnych w praktyce

Question

To pytanie może być bardziej odpowiednie dla programistów.stackexchange. Jeśli tak, przeprowadź migrację.

Obecnie rozważam złożoność typowych modeli danych. Każdy wie, że modele danych powinny być znormalizowane, jednak z drugiej strony znormalizowany model danych będzie wymagał kilku złączeń do ponownego złożenia danych później. Połączenia są potencjalnie kosztownymi operacjami, w zależności od rozmiaru użytych tabel. Więc pytanie, które usiłuję rozgryźć, brzmi: jak zwykle chodzi o tę kompromis? To znaczy. w praktyce ilu łączeń można uznać za dopuszczalne w typowych zapytaniach podczas projektowania modelu danych? Byłoby to szczególnie interesujące przy liczeniu wielu połączeń w pojedynczych zapytaniach.

Jako przykład załóżmy, że mamy użytkowników, którzy posiadają domy, w których są pokoje, które mają szuflady, które zawierają przedmioty. Trivially normalizowanie tego za pomocą tabel dla użytkowników, domów, pokojów, szuflad i przedmiotów w sensie wyjaśnionym powyżej, wymagałoby później, abym dołączył do pięciu tabel, podczas pobierania wszystkich elementów należących do określonego użytkownika. Wydaje mi się to bardzo skomplikowane.

Najprawdopodobniej dotyczy to również rozmiarów stołów. Łączenie pięciu tabel z niewielką ilością danych nie jest tak złe, jak trzy tabele z milionami wierszy. Czy jest to błędne?

Answer 1

Jest reasons for the Database Normalizations i widziałem zapytania z ponad 20 tabelami i subdomenami, które są ze sobą połączone i działają dobrze przez długi czas. Uważam, że koncepcja normalizacji jest ogromną wygraną, ponieważ pozwala mi wprowadzić nowe funkcje, które zostaną dodane do istniejących działających aplikacji bez wpływu na dotychczas działające części.

Bazy danych pochodzi z różnych funkcji, aby ułatwić Ci życie:

• można utworzyć widoki dla najczęściej używanych zapytań (chociaż nie jest to jedyny przypadek użycia dla widoków);
• niektóre RDBMS zapewnia Common Table Expressions (CTE), które pozwalają na używanie nazwanych pod-zapytań, a także kwerend rekursywnych;
• Niektóre RDBMS udostępnia języki rozszerzające (takie jak PL/SQL lub PL/pgSQL), które pozwalają rozwijać własne funkcje, aby ukryć złożoność schematu i używać tylko wywołań API do obsługi danych.

Jakiś czas temu pojawił się jakiś pokrewny pytanie na temat How does a SQL statement containing mutiple joins work? Warto byłoby również przyjrzeć się temu.

Tworzenie aplikacji ze znormalizowaną bazą danych jest łatwiejsze, ponieważ dzięki odpowiedniemu podejściu można wyizolować swój schemat za pomocą widoków/funkcji i uczynić kod aplikacji odpornym na zmiany schematu. Jeśli zdecydujesz się na zdenormalizowany projekt, może się zdarzyć, że zmiany w projekcie wpłyną na znaczną część twojego kodu, ponieważ zdenormalizowane systemy są zwykle wysoce zoptymalizowane pod kątem kosztów zmian.

Answer 2

Całkowicie znormalizowany model danych ma większy koszt pod względem wydajności, ale jest bardziej odporny na zmiany. Model danych płaskich jako banknot dostrojony do jednego zapytania będzie działał znacznie lepiej, ale będziesz musiał zapłacić cenę, gdy specyfikacja się zmieni.

Może więc pytanie, czy korzystanie z modelu danych (zapytań) zmieni się bardzo? Jeśli nie; nie normalizuj ich, tylko dostosuj je do konkretnych zapytań (zapytaj administratora DBA). W przeciwnym razie, normalizując i tuż po planie wykonania zapytania, jeśli użyjesz wielu złączeń, nie mogę podać konkretnego numeru.

Answer 3

Normalizowanie baz danych jest formą sztuki samo w sobie.
Jeśli prawidłowo ułożysz swoje połączenia, będziesz tylko chwytał potrzebne kolumny.
Powinno być znacznie szybciej uruchomić kwerendę z milionami rekordów z wieloma tabelami i po prostu dołączając potrzebne pola, to wtedy, gdybyś powiedział jedną lub dwie tabele ze wszystkimi rekordami. W drugim przykładzie pobierasz wszystkie dane, a ich sortowanie będzie koszmarem kodującym.
MySQL jest bardzo dobry, pobiera tylko żądane dane.
To, że zapytanie jest długie, nie oznacza, że ​​jest wolniejsze.
Widziałem instrukcje zapytań ponad 20 linii kodu, które były bardzo szybkie.

Zaufaj zapytaniu, które napiszesz, a jeśli nie napiszesz skryptu testowego, wypróbuj go sam.

Answer 4

Aby rozwiązać swoje pytanie odpowiedź jest:

http://en.wikipedia.org/wiki/Database_normalization

Jeśli wydajność staje się problemem za pomocą Denormalizacja te problemy mogą być rozwiązane. Myślenie o tym kroku z góry (chyba że masz już oczekiwany ładunek) nie powinno być zrobione. Denormalizuj, kiedy jest naprawdę potrzebny i oparty na pomiarach.