pojedyncza ustalona tabela z wieloma kolumnami vs elastyczne tabele abstrakcyjne

Niektóre problemy należy wyjaśnić i rozwiązać przed możemy rozpocząć rozsądną dyskusję.

Wstępna rozdzielczość

Etykiety
W zawodzie, który wymaga precyzji, ważne jest, aby używać precyzyjnych etykiet, aby uniknąć nieporozumień i abyśmy mogli komunikować się bez konieczności używania długich opisów i kwalifikatorów.

To, co zamieściłeś jako FixedTables, jest nieznormalizowane . W porządku, może to być próba użycia trzeciej formy normalnej, ale w rzeczywistości jest to płaski plik, nieznormalizowany (nie „zdenormalizowany). To, co zamieściłeś jako Abstrakt Tabele, to, mówiąc ściślej, Wartość-atrybutu encji , który jest prawie, ale nie całkiem, szóstą formą normalną i dlatego jest bardziej znormalizowany niż 3NF. Zakładając oczywiście, że jest to zrobione poprawnie.
- Plik tekstowy Nieznormalizowany nie jest „zdenormalizowany”. Jest pełen duplikatów (nic nie zostało zrobione, aby usunąć powtarzające się grupy i zduplikowane kolumny lub rozwiązać zależności) i zerowe, na wiele sposobów ogranicza wydajność i zapobiega współbieżności.
- Aby można było ją zdenormalizować, najpierw należy ją znormalizować, a następnie z jakiegoś ważnego powodu normalizację nieco cofnąć. Ponieważ nie jest on w pierwszej kolejności znormalizowany, nie można go zdenormalizować. Jest po prostu nieznormalizowany.
- Nie można powiedzieć, że jest zdenormalizowany „dla wydajności”, ponieważ będąc świnią wydajności, jest samą antytezą wydajności. Cóż, potrzebują uzasadnienia dla braku sformalizowanego projektu], a „dla wydajności” to jest. Nawet najmniejsza formalna kontrola ujawniła nieprawdziwe informacje (ale bardzo niewiele osób może to przedstawić, więc pozostaje to ukryte, dopóki ktoś z zewnątrz nie zajmie się, jak zgadłeś, ogromnym problemem z wydajnością).
- Struktury znormalizowane działają znacznie lepiej niż struktury nieznormalizowane. Bardziej znormalizowane struktury (EAV/6NF) działają lepiej niż mniej znormalizowane struktury (3NF/5NF).
- Zgadzam się z ideą kucyków OMG, ale nie z ich etykietami i definicjami
- zamiast mówić „nie „denormalizuj”, chyba że musisz” , mówię, „Normalizuj wiernie, kropka” i „jeśli występuje problem z wydajnością, nie została prawidłowo znormalizowana” .
Wikipedia
Pozycje formularzy normalnych i normalizacji zawierają niepoprawne definicje; mylą Normalne Formy; brakuje ich w procesie Normalizacji; i przywiązują równą wagę do absurdalnych lub wątpliwych NF, które zostały zdemaskowane dawno temu. W rezultacie Wikipedia dodaje do już pomieszanego i rzadko rozumianego tematu. Więc nie trać czasu.

Jednak, aby zrobić postęp, bez tego odniesienia stanowiącego przeszkodę, powiem to.
- Definicja 3NF jest stabilna i nie uległa zmianie.
- Istnieje duże zamieszanie w NF pomiędzy 3NF i 5NF. Prawda jest taka, że jest to obszar, który rozwinął się w ciągu ostatnich 15 lat; a wiele organizacji, naukowców, a także sprzedawców z ograniczeniami swoich produktów, przeskoczyło, aby stworzyć nowy „Normalny formularz”, aby zweryfikować swoje oferty. Wszystkie służą interesom komercyjnym i nie mają podstaw akademickich. 3NF w swoim pierwotnym, nienaruszonym stanie przewidywał i gwarantował określone atrybuty.
- W sumie 5NF jest dzisiaj, tym, czym 3NF miał być 15 lat temu, i możesz pominąć komercyjne przekomarzanie się i mniej więcej dwanaście „specjalnych” (komercyjnych i pseudoakademickich) NF pomiędzy, niektórymi z których są zidentyfikowane w Wikipedii, a nawet w mylących terminach.
Piąta forma normalna
Ponieważ udało Ci się zrozumieć i zaimplementować EAV w swoim poście, nie będziesz miał problemu ze zrozumieniem poniższych kwestii. Oczywiście warunkiem wstępnym jest prawdziwy model relacyjny, silne klucze itp. Piąta forma normalna to, ponieważ pomijamy czwartą:
- Trzecia forma normalna
  - co w prostych, definitywnych terminach oznacza, że każda kolumna niebędąca kluczem w każdej tabeli ma relację 1::1 z kluczem podstawowym tabeli,
  - i do żadnych innych kolumn bez klucza
- Zerowe powielanie danych (wynik, jeśli Normalizacja postępuje sumiennie; nie osiąga się tylko dzięki inteligencji lub doświadczeniu lub pracy nad tym jako cel bez formalnego procesu)
- brak anomalii aktualizacji (kiedy aktualizujesz gdzieś kolumnę, nie musisz aktualizować tej samej kolumny znajdującej się gdzie indziej; kolumna istnieje w jednym i tylko jednym miejscu).
- Jeśli rozumiesz powyższe, 4NF, BCNF i wszystkie głupie „NF” można odrzucić, są one wymagane w przypadku fizycznych systemów archiwizacji danych, promowanych przez naukowców, całkiem obcych w stosunku do modelu relacyjnego (Codd).
Szósta forma normalna
- Celem jest eliminacja brakujących danych (kolumny atrybutów), czyli eliminacja wartości Null
- Jest to jedyne prawdziwe rozwiązanie problemu zerowego (zwanego również obsługą brakujących wartości), a wynikiem jest baza danych bez wartości zerowych. (Można to zrobić przy 5NF ze standardami i substytutami Null, ale to nie jest optymalne.) Jak interpretujesz i wyświetlasz brakujące wartości to inna historia.
- Technicznie nie jest to prawdziwa forma normalna, ponieważ nie ma 5NF jako warunku wstępnego, ale ma wartość
EAV kontra szósta forma normalna
Wszystkie bazy danych, które napisałem, z wyjątkiem jednej, to czysty 5NF. Pracowałem z (administrowanymi, naprawionymi, ulepszonymi) kilkoma bazami danych EAV i zaimplementowałem wiele prawdziwych baz danych 6NF. EAV to luźna implementacja 6NF, często wykonywana przez ludzi, którzy nie mają dobrej znajomości normalizacji i NF, ale widzą wartość i potrzebują elastyczności EAV. Jesteś doskonałym przykładem.

Różnica jest taka:ponieważ jest luźna i ponieważ implementatorzy nie mają odniesienia (6NF), aby być wiernym, implementują tylko to, czego potrzebują, i piszą to wszystko w kodzie; co kończy się niespójnym modelem.

Podczas gdy czysta implementacja 6NF ma czysto akademicki punkt odniesienia, a zatem jest zwykle ściślejsza i spójniejsza. Zwykle pojawia się to w dwóch widocznych elementach:
- 6NF ma katalog zawierający metadane, a wszystko jest zdefiniowane w metadanych, a nie w kodzie. EAV go nie ma, wszystko jest w kodzie (implementatorzy śledzą obiekty i atrybuty). Oczywiście katalog ułatwia dodawanie kolumn, nawigację i umożliwia tworzenie narzędzi.
- 6NF, jeśli jest zrozumiałe, zapewnia prawdziwe rozwiązanie problemu zerowego. Realizatory EAV, ponieważ nie mają kontekstu 6NF, obsługują brakujące dane w kodzie, niespójnie lub, co gorsza, zezwalają na wartości Null w bazie danych. Realizatorzy 6NF nie zezwalają na wartości Null i obsługują brakujące dane spójnie i elegancko, bez konieczności konstruowania kodu (do obsługi wartości Null; oczywiście nadal musisz kodować brakujące dane).

Np. W przypadku baz danych 6NF z katalogiem mam zestaw procedur, które [re]generują SQL wymagany do wykonania wszystkich operacji SELECT, i udostępniam widoki w 5NF dla wszystkich użytkowników, więc nie muszą znać ani rozumieć podstawowej struktury 6NF . Są usuwane z katalogu. Dzięki temu zmiany są łatwe i zautomatyzowane. Typy EAV robią to ręcznie, ze względu na brak katalogu.

Dyskusja

Teraz możemy rozpocząć dyskusję.

"Oczywiście może to być bardziej abstrakcyjne, jeśli wartości są wstępnie zdefiniowane (przykład:specjalności mogą mieć własną listę)"

Pewny. Ale nie bądź zbyt „abstrakcyjny”. Zachowaj spójność i wdrażaj takie listy w ten sam sposób EAV (lub 6NF), jak inne listy.

„Jeśli przyjmę podejście abstrakcyjne, może to być bardzo elastyczne, ale zapytania będą bardziej złożone z dużą ilością złączeń. Ale nie wiem, czy ma to wpływ na wydajność wykonywania tych „bardziej złożonych” zapytań”.

W relacyjnych bazach danych złączenia to ruch pieszy. Problemem nie jest baza danych, problem polega na tym, że SQL jest niewygodny podczas obsługi złączeń, zwłaszcza kluczy złożonych.
Bazy danych EAV i 6NF mają więcej złączeń, które podobnie jak dla pieszych, nie więcej, nie mniej. Jeśli musisz zakodować każdy SELECT ręcznie, z pewnością kłopotliwe staje się naprawdę kłopotliwe.
Cały problem można wyeliminować poprzez (a) przejście z 6NF przez EAV i (b) zaimplementowanie katalogu, z którego można (c) wygenerować wszystkie podstawowe SQL. Eliminuje również całą klasę błędów.
Powszechnym mitem jest to, że łączenia jakoś mają swój koszt. Całkowicie fałszywe.
- Dołączenie jest implementowane w czasie kompilacji, nie ma nic istotnego do „kosztowania” cykli procesora.
- Problemem jest rozmiar tabel dołączenia, a nie koszt połączenia między tymi samymi stołami.
- Łączenie dwóch tabel z milionami wierszy każda, na poprawnej relacji PK⇢FK, z których każda ma odpowiednie indeksy
  (Unikalne po stronie rodzica [PK]; Unikalne po stronie dziecka [PK=rodzic FK + coś]
  jest natychmiastowe
- Gdzie indeks Child nie jest unikalny, ale przynajmniej wiodące kolumny są prawidłowe, jest wolniejszy; gdzie nie ma użytecznego indeksu, oczywiście jest bardzo powolny.
- Nie ma to nic wspólnego z kosztem dołączenia.
- Gdy zwracanych jest wiele wierszy, wąskim gardłem będzie sieć i układ dysku; nie przetwarzanie łączenia.
Dzięki temu możesz uzyskać tak „skomplikowany”, jak tylko chcesz, bez żadnych kosztów, SQL może to obsłużyć.

Chciałbym wiedzieć, jakie są zalety i wady obu metod. Mogę sobie tylko wyobrazić, ale nie mam doświadczenia, aby to potwierdzić.

5NF (lub 3NF dla tych, którzy nie zrobili progresji) jest najłatwiejszy i najlepszy pod względem implementacji; łatwość obsługi (programiści jak i użytkownicy); i konserwacja.
- Wadą jest to, że za każdym razem, gdy dodajesz kolumnę, musisz zmienić strukturę bazy danych (tabela DDL). To jest w porządku w niektórych przypadkach, ale nie w większości przypadków ze względu na kontrolę zmian w miejscu, dość uciążliwe.
- Po drugie, musisz zmienić istniejący kod (kod obsługujący nową kolumnę się nie liczy, bo jest to konieczne):tam, gdzie wdrażane są dobre standardy, to jest minimalizowane; tam, gdzie ich nie ma, zakres jest nieprzewidywalny.
EAV (czyli to, co zamieściłeś), umożliwia dodawanie kolumn bez zmian DDL. To jest jedyny powód, dla którego ludzie go wybierają. (kod obsługujący nową kolumnę nie liczy się, ponieważ jest to konieczne). Jeśli zostanie dobrze zaimplementowany, nie wpłynie to na istniejący kod; jeśli nie, to będzie.
Ale potrzebujesz programistów obsługujących EAV.
- Kiedy EAV jest źle zaimplementowany, jest to okropne, gorszy bałagan niż 5NF zrobiony źle, ale nie gorszy niż Nieznormalizowany, co jest tym, co jest w większości baz danych (błędnie przedstawiane jako „zdenormalizowane pod kątem wydajności”).
- Oczywiście, nawet ważniejsze (niż w 5NF/3NF) jest utrzymywanie silnego kontekstu Transakcji, ponieważ kolumny są znacznie bardziej rozłożone.
- Podobnie ważne jest, aby zachować deklaratywną integralność referencyjną:bałagan, który widziałem, był w dużej mierze spowodowany usunięciem DRI przez programistów, ponieważ stało się „zbyt trudne do utrzymania”, w wyniku czego, jak możesz sobie wyobrazić, była jedna matka stosu danych ze zduplikowanymi wierszami i kolumnami 3NF/5NF w całym miejscu. I niespójna obsługa wartości Null.
Nie ma różnicy w wydajności, zakładając, że serwer został odpowiednio skonfigurowany do zamierzonego celu. (Ok, są konkretne optymalizacje możliwe tylko w 6NF, które nie są możliwe w innych NF, ale myślę, że jest to poza zakresem tego wątku.) I znowu źle zrobiony EAV może powodować niepotrzebne wąskie gardła, nie bardziej niż Nieznormalizowane.
Oczywiście, jeśli wybierasz się z EAV, polecam więcej formalności; kup pełny funt; iść z 6NF; wdrożyć katalog; narzędzia do tworzenia SQL; Wyświetlenia; konsekwentnie obsługiwać brakujące dane; całkowicie wyeliminować Nulls. Zmniejsza to twoją podatność na jakość twoich programistów; mogą zapomnieć o ezoterycznych problemach EAV/6NF, używać widoków i skoncentrować się na logice aplikacji.