Jakie są [dis]zalety używania tabeli klucz / wartość nad kolumnami lub oddzielnymi tabelami, które można anulować?

Aktualizuję system zarządzania płatnościami, który stworzyłem jakiś czas temu. Obecnie ma jedną tabelę dla każdego rodzaju płatności, który może zaakceptować. Ogranicza się tylko do możliwości płacenia za jedną rzecz, którą ta aktualizacja ma złagodzić. Prosiłem o sugestie, jak to zaprojektować, i mam te podstawowe pomysły do pracy z:

  1. mają jedną tabelę dla każdego rodzaju płatności, z kilkoma wspólnymi kolumnami na każdej. (current design)
  2. skoordynuj wszystkie płatności z centralną tabelą przyjmuje wspólne kolumny (ujednolicając identyfikatory płatności niezależnie od typu) i identyfikuje inną tabelę i identyfikator wiersza, które mają kolumny wyspecjalizowane dla tego typu płatności.
  3. mają jedną tabelę dla wszystkich typów płatności, a null kolumny, które nie są używane dla danego typu.
  4. Użyj idei tabeli centralnej, ale przechowuj wyspecjalizowane kolumny w tabeli klucz / wartość.

Moje cele to: nie śmiesznie powolny, samokontrola jak najwięcej i maksymalizacja elastyczności podczas utrzymanie innych celów.

Nie lubię 1 bardzo ze względu na zduplikowane kolumny w każdej tabeli. Odzwierciedla ona klasy typu płatności dziedziczące klasę bazową, która zapewnia funkcjonalność dla wszystkich typów płatności... ORM w odwrotnej kolejności?

Skłaniam się ku 2 najbardziej, ponieważ jest tak samo "bezpieczny" i samodokumentujący się jak obecny projekt. Ale, podobnie jak w przypadku 1, aby dodać nowy rodzaj płatności, muszę dodać nową tabelę.

Nie lubię 3 ze względu na "zmarnowaną przestrzeń", a to nie od razu jasne, które kolumny są używane dla jakich rodzajów płatności. Dokumentacja może nieco złagodzić ten ból, ale wewnętrzne narzędzia mojej firmy nie mają skutecznej metody przechowywania / znajdowania dokumentacji technicznej.

Argumentem, który otrzymałem za 4, było to, że zmniejszy to potrzebę zmiany bazy danych przy dodawaniu nowej metody płatności, ale cierpi jeszcze gorzej niż 3 z powodu braku jasności. Obecnie zmiana bazy danych nie stanowi problemu, ale może stać się logistycznym koszmarem, jeśli zdecydujemy się pozwolić klientom prowadzić własną bazę danych.

Więc, oczywiście, że mam swoje uprzedzenia. Ma ktoś lepszy pomysł? Który projekt według ciebie pasuje najlepiej? Na jakich kryteriach należy oprzeć swoją decyzję?

Author: Taudris, 2010-10-30

5 answers

Być może powinieneś spojrzeć na to pytanie

Zaakceptowana odpowiedź od Billa Karwina przechodzi w konkretne argumenty przeciwko tabeli klucza / wartości, Zwykle znanej jako wartość atrybutu encji (EVA)

.. Chociaż wiele osób zdaje się faworyzować EAV, ja nie. wydaje się, że najbardziej elastyczne rozwiązanie, a tym samym najlepszy. Należy jednak pamiętać o przysłowie TANSTAAFL . Oto niektóre z wady EAV:

  • No way to make a column obowiązkowe (odpowiednik NOT NULL).
  • nie ma możliwości użycia typów danych SQL do walidacji wpisów.
  • nie ma możliwości zapewnienia, że nazwy atrybutów są pisane konsekwentnie.
  • nie ma sposobu na umieszczenie klucza obcego na wartościach danego atrybutu, np. do tabeli wyszukiwania.
  • pobieranie wyników w konwencjonalnym układzie tabelarycznym jest złożone i drogie, bo aby uzyskać atrybuty z wielu wierszy musisz zrobić JOIN dla każdego atrybutu.

Stopień elastyczność EAV daje wymaga poświęceń w innych obszary, prawdopodobnie tworząc swój kod jako skomplikowany (lub gorszy) niż było rozwiązać oryginalny problem w bardziej konwencjonalny sposób.

I w większości przypadków jest to niepotrzebne mieć taki stopień elastyczności. W pytaniu OP o produkt typów, znacznie łatwiej jest stworzyć tabela dla poszczególnych rodzajów produktu atrybutów specyficznych dla produktu, więc ty mieć jakąś spójną strukturę egzekwowane przynajmniej dla wpisy na temat ten sam typ produktu.

Użyłbym EAV tylko wtedy, gdy każdy wiersz musi być dopuszczony do potencjalnie odrębny zestaw atrybutów. Kiedy ty posiadają skończony zbiór typów produktów, Podsłuchy to przesada. Tabela Klasowa Spadek byłby moim pierwszym wyborem.

 8
Author: Conrad Frix,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:09:42

Uwaga
ten temat jest omawiany, a ten wątek jest odwołany w innych wątkach, dlatego dałem mu rozsądne traktowanie, proszę o cierpliwość. Moim zamiarem jest zapewnienie zrozumienia, abyście mogli podejmować świadome decyzje, a nie uproszczone decyzje oparte wyłącznie na etykietach. Jeśli uważasz, że jest intensywny, przeczytaj go w kawałkach, w wolnym czasie; wróć, gdy jesteś głodny, a nie wcześniej.

Co dokładnie w EAV jest " złe" ?

1 Wprowadzenie

Jest różnica między EAV wykonanym prawidłowo, a wykonanym źle, tak jak jest różnica między 3NF wykonanym prawidłowo a wykonanym źle. W naszej pracy technicznej musimy być precyzyjni, co dokładnie działa, a co nie; co działa dobrze, a co nie. ogólne stwierdzenia są niebezpieczne, wprowadzają w błąd ludzi, a tym samym utrudniają postęp i powszechne zrozumienie odnośnych zagadnień.

Nie jestem za ani przeciw wszystko, z wyjątkiem słabych wdrożeń przez niewykwalifikowanych pracowników i błędnego przedstawiania poziomu zgodności ze standardami. I tam, gdzie widzę nieporozumienie, jak tutaj, postaram się go rozwiązać.

Normalizacja jest również często źle rozumiana, więc jedno słowo na ten temat. Wiki i inne wolne źródła faktycznie publikują całkowicie bezsensowne "definicje", które nie mają podstaw akademickich, które mają uprzedzenia dostawców, aby zweryfikować swoje niestandardowe produkty. Codd opublikował swoje dwanaście Zasady. Wdrażam minimum 5NF, co jest więcej niż wystarczające dla większości wymagań, więc użyję tego jako podstawy. Mówiąc najprościej, przy założeniu, że trzecia normalna forma jest rozumiana przez czytelnika (przynajmniej ta definicja nie jest mylona) ...

2 Piąta Postać Normalna

2.1 definicja

Piąta postać normalna jest zdefiniowana jako:

  • każda kolumna ma relację 1::1 z kluczem głównym, tylko
  • i do żadnej innej kolumny, w tabeli, ani w żadnej inna tabela
  • rezultatem jest brak duplikatów kolumn, w dowolnym miejscu; Brak anomalii aktualizacji(brak potrzeby wyzwalaczy lub skomplikowanego kodu, aby zapewnić, że gdy kolumna jest aktualizowana, jej duplikaty są aktualizowane poprawnie).
  • [32]}poprawia wydajność, ponieważ (A) wpływa na mniejszą liczbę wierszy i (b) poprawia współbieżność dzięki zmniejszonemu blokowaniu

Rozróżniam, że nie jest tak, że baza danych jest znormalizowana do konkretnego NF lub nie; baza danych jest po prostu znormalizowana. On że każda tabela jest znormalizowana do określonego NF: niektóre tabele mogą wymagać tylko 1NF, inne 3NF, a jeszcze inne wymagają 5NF.

2.2 wydajność

Był czas, kiedy ludzie myśleli, że normalizacja nie zapewnia wydajności i musieli "denormalizować wydajność". Dzięki Bogu ten mit został obalony, a większość specjalistów IT zdaje sobie dziś sprawę, że znormalizowane bazy danych działają lepiej. Dostawcy baz danych optymalizują dla znormalizowanych baz danych, a nie dla systemów plików denormllized. Prawda "denormalizowana" jest taka, że baza danych nie była znormalizowana w pierwszej kolejności (i działała źle), była nieznormalizowana, a oni robili jakieś dalsze zamieszanie w celu poprawy wydajności. Aby zostać Denormalizowana, musi być najpierw wiernie znormalizowana, a do tego nigdy nie doszło. Przepisałem partytury takich" denormalizowanych dla wydajności " baz danych, zapewniając wierną normalizację i nic więcej, a w nich było co najmniej dziesięć, a nawet sto, razy szybciej. Ponadto wymagały one tylko ułamka miejsca na dysku. To jest tak piesze, że gwarantuję ćwiczenie na piśmie.

2.3 ograniczenie

Ograniczenia, a raczej pełny zakres 5NF to:

  • nie obsługuje wartości opcjonalnych, a null muszą być używane (wielu projektantów nie zezwala na NULL i używa substytutów, ale ma to ograniczenia, jeśli nie jest zaimplementowane prawidłowo i konsekwentnie)
  • nadal musisz się zmienić DDL w celu dodania lub zmiany kolumn (i jest coraz więcej wymagań, aby dodać kolumny, które nie zostały początkowo zidentyfikowane, po implementacji; Kontrola zmian jest uciążliwa)
  • chociaż zapewnia najwyższy poziom wydajności ze względu na normalizację( Czytaj: eliminację duplikatów i mylonych relacji), złożone zapytania, takie jak pivoting (tworzenie raportu wierszy lub podsumowań wierszy, wyrażonych jako kolumny) i "dostęp kolumnowy" wymagany do operacji hurtowni danych, są trudne, i tylko te operacje, nie wykonują się dobrze. Nie jest to spowodowane tylko dostępnym poziomem umiejętności SQL, a nie silnikiem.

3 Szósta Postać Normalna

3.1 definicja

Szósta postać normalna jest zdefiniowana jako:

    W zależności od tego, czy jest to klucz podstawowy, czy też jeden atrybut (kolumna), Relation (wiersz) jest kluczem podstawowym.]}

Jest znana jako nieredukowalna postać normalna, ostateczny NF, ponieważ nie ma więcej Normalizacja, którą można wykonać . Choć była ona omawiana w kręgach akademickich w połowie lat dziewięćdziesiątych, formalnie została ogłoszona dopiero w 2003 roku. Dla tych, którzy lubią oczerniać formalność modelu relacyjnego, poprzez mylenie relacji, relwarów, "relacji" i tym podobnych: wszystkie te nonsensy można położyć na nogi, ponieważ formalnie powyższa definicja identyfikuje Nieredukowalną relację , czasami nazywaną relacją atomową.

3.2 Progresja

The przyrost, który zapewnia 6NF (którego nie zapewnia 5NF) wynosi:

  • formalne wsparcie dla wartości opcjonalnych, a tym samym wyeliminowanie problemu Null
      Efekt uboczny polega na tym, że kolumny mogą być dodawane bez zmian DDL (więcej później)
  • łatwe obracanie
  • prosty i bezpośredni dostęp kolumnowy
      Pozwala to (nie w swojej waniliowej formie) na jeszcze większy poziom wydajności w tym dziale [33]}
  • Powiem, że ja (i inni) dostarczaliśmy ulepszone tabele 5NF 20 lat temu, wprost do obracania, bez żadnego problemu, a tym samym pozwalając (a) na używanie prostego SQL i (b) zapewniając bardzo wysoką wydajność; miło było wiedzieć, że akademiccy giganci branży formalnie zdefiniowali, co robimy. W nocy moje tabele 5NF zostały przemianowane na 6NF, bez mnie podnosząc palcem. Po drugie, zrobiliśmy to tylko tam, gdzie tego potrzebowaliśmy; ponownie, to Tabela, a nie baza danych, została znormalizowana do 6NF.

    3.3 SQL Ograniczenie

    Jest to język uciążliwy, szczególnie realny, a robienie czegokolwiek umiarkowanie skomplikowanego sprawia, że jest onbardzo uciążliwy. (Jest to osobna kwestia, której większość programistów nie rozumie ani nie używa zapytań podrzędnych.) Obsługuje struktury wymagane dla 5NF, ale tylko po prostu. W przypadku solidnych i stabilnych wdrożeń należy wdrożyć dodatkowe standardy, które mogą składać się częściowo z dodatkowych tabel katalogowych. Data "use by" dla SQL ' a upłynęła na początku lat dziewięćdziesiątych; jest całkowicie pozbawiony wsparcia dla tabel 6NF i rozpaczliwie potrzebuje wymiany. Ale to wszystko, co mamy, więc musimy sobie z tym poradzić.

    Dla tych z nas, którzy wdrażali standardy i dodatkowe tabele katalogowe, nie było poważnym wysiłkiem rozszerzenie naszych katalogów o możliwości wymagane do obsługi struktur 6NF do standardu : które kolumny należą do których tabel i w jakiej kolejności; obowiązkowe / Opcjonalne; wyświetlanie format; itp. Zasadniczo pełny katalog metadanych, połączony z katalogiem SQL.

    Zauważ, że każde NF zawiera w sobie każde poprzednie NF, więc 6NF zawiera 5NF. Nie złamaliśmy 5NF w celu dostarczenia 6NF, podaliśmy Progres od 5NF; a gdzie SQL się nie udał, podaliśmy katalog. Oznacza to podstawowe ograniczenia, takie jak dla kluczy obcych; i domeny wartości, które zostały dostarczone poprzez deklaratywną Referencjalną integralność SQL; typy danych; kontrole; i reguły, na poziomie 5NF, pozostały nienaruszone, a ograniczenia te nie zostały naruszone. Wysoka jakość i wysoka wydajność zgodnych ze standardami baz danych 5NF nie została zmniejszona przez wprowadzenie 6NF.

    3.4 Katalog

    Ważne jest, aby chronić użytkowników (każde narzędzie do raportowania) i deweloperów, przed koniecznością radzenia sobie ze skokiem z 5NF do 6NF (ich zadaniem jest być maniakami kodowania aplikacji, moim zadaniem jest być maniakiem baz danych). Nawet w 5NF, to zawsze był dla mnie cel projektowy: prawidłowo Znormalizowana baza danych, z minimalnym katalogiem danych, jest w rzeczywistości dość łatwa w użyciu i nie było mowy, żebym z tego zrezygnował. Należy pamiętać, że ze względu na normalną Konserwację i rozbudowę, struktury 6NF zmieniają się w czasie, nowe wersje bazy danych są publikowane w regularnych odstępach czasu. Bez wątpienia SQL (już uciążliwy w 5NF) wymagany do zbudowania wiersza 5NF z tabel 6NF, jest jeszcze bardziej uciążliwy. Z wdzięcznością, to zupełnie niepotrzebne.

    Ponieważ już miał nasz katalog, który zidentyfikował pełną 6NF-DDL-że-SQL-nie-zapewnia, Jeśli chcesz, napisałem małe narzędzie do czytania katalogu i:

    • wygenerowanie tabeli 6NF DDL.
    • generowanie widoków 5NF tabel 6NF. To pozwoliło użytkownikom pozostać błogiej nieświadomości o nich i dało im te same możliwości i wydajność, jakie mieli w 5NF
    • wygenerować pełny SQL (nie szablon, mamy te osobno) wymagany do działania na strukturach 6NF, które kodery następnie używać. Są one uwalniane od nudy i powtórzeń, które są w przeciwnym razie wymagane, i swobodnie skoncentrować się na logice aplikacji.

    Nie napisałem narzędzia do obracania, ponieważ złożoność obecna w 5NF jest wyeliminowana, a teraz są one martwe proste do napisania, jak w przypadku 5NF-enhanced-for-pivoting. Poza tym większość narzędzi do raportowania zapewnia pivoting, więc muszę tylko zapewnić funkcje, które obejmują ciężkie generowanie statystyk, które muszą być wykonywane na serwerze przed wysyłką do klienta.

    3.5 wydajność

    Każdy ma swoją" chorobę", którą musi cierpieć, swój krzyż, który musi dźwigać; ja mam obsesję na punkcie performansu. Moje bazy danych 5NF działały dobrze, więc zapewniam cię, że przeprowadziłem znacznie więcej testów, niż było to konieczne, przed wprowadzeniem czegokolwiek do produkcji. Baza danych 6NF działała dokładnie tak samo jak baza danych 5NF, nie lepiej, nie gorzej. Nie jest to zaskoczeniem, ponieważ jedyne, co robi" złożony " 6NF SQL, to 5NF SQL nie wykonuje, wykonuje znacznie więcej złączeń i zapytań podrzędnych.

    Musisz zbadać mity.

    • każdy, kto zbadał problem (tj. zbadał plany wykonania zapytań), będzie wiedział, że dołączenie nic nie kosztuje, jest to rozdzielczość w czasie kompilacji, nie mają one wpływu na czas wykonania.
    • Tak, oczywiście, liczba połączonych tabel; rozmiar połączonych tabel; czy można używać indeksów; rozkład połączonych kluczy; itd., Wszystkie coś kosztowało.
    • Ale samo połączenie nic nie kosztuje.
    • Zapytanie o pięć (większych) tabel w Nieznormalizowanej bazie danych jest znacznie wolniejsze niż Zapytanie o dziesięć (mniejszych) tabel w tej samej bazie danych, jeśli zostało znormalizowane. chodzi o to, że ani cztery, ani dziewięć połączeń nic nie kosztuje; nie figurują w problemie wydajności; wybrany zestaw na każdym połączeniu nie figuruje w nim.

    3.6 Benefit

    1. Dostęp. To tutaj 6NF naprawdę wyróżnia się. Prosty dostęp kolumnowy był tak szybki, że nie było potrzeby eksportowania danych do hurtowni danych w celu uzyskania prędkości od wyspecjalizowanych struktur DW.

      Moje badania nad kilkoma DWs, bynajmniej nie kompletnymi, pokazują, że konsekwentnie przechowują dane według kolumn, w przeciwieństwie do wierszy, co dokładnie robi 6NF. Jestem konserwatywny, więc nie zamierzam składać żadnych deklaracji, że 6NF wyprze DWs, ale w moim przypadku wyeliminował potrzebuję jednego.

    2. Nie byłoby sprawiedliwe porównywanie funkcji dostępnych w 6NF, które były niedostępne w 5NF (np. Pivoting), który oczywiście przebiegał znacznie szybciej.

    To była nasza pierwsza prawdziwa baza danych 6NF (z pełnym katalogiem itp.; w przeciwieństwie do zawsze 5NF z ulepszeniami tylko w razie potrzeby; który później okazał się być 6NF), a klient jest bardzo zadowolony. Oczywiście monitorowałem wydajność przez jakiś czas po porodzie i zidentyfikowałem jeszcze szybszy metoda dostępu kolumnowego do mojego następnego projektu 6NF. To, gdy to zrobię, może stanowić trochę konkurencji dla rynku DW. Klient nie jest gotowy, a my nie naprawiamy tego, co nie jest zepsute.

    3.7 co, dokładnie, o 6NF, jest "złe"?

    Zauważ, że nie każdy podchodzi do pracy z taką formalnością, strukturą i przestrzeganiem standardów. Głupio byłoby więc wnioskować z naszego projektu, że wszystkie bazy danych 6NF działają dobrze i są łatwe do utrzymać. Równie głupim byłoby wnioskować (patrząc na implementacje innych), że wszystkie bazy danych 6NF działają źle, są trudne do utrzymania;) Jak zawsze, przy każdym przedsięwzięciu technicznym, wynikająca z tego wydajność i łatwość konserwacji są ściśle zależne od formalności, struktury i przestrzegania standardów, oprócz odpowiedniego zestawu umiejętności.

    3.8 dostępność

    Proszę się nie ujawniać i prosić o coś poza granicami standardowa praktyka handlowa, taka jak "opublikowane Referencje", klient jest australijskim bankiem, Cała realizacja jest poufna; ale jestem wolny, aby przyjmować perspektywy na wizyty. Zapraszamy również do przeglądania (ale nie kopiowania) dokumentacji w naszych biurach w Sydney. Metodologia (struktury i standardy poza publicznie dostępną edukacją 6NF) i narzędzia, jest naszą zastrzeżoną własnością intelektualną i jest dostępna dla zadań. Na tym etapie sprzedaję go tylko jako część zadania, ponieważ (a) muszę rozsądnie zapewnić sukces projektu (aby nie zaszkodzić naszej reputacji), oraz (b) jeden udany projekt pod naszymi ramionami nie jest wystarczająco dojrzały, aby sklasyfikować go jako "gotowy do rynku".

    Cieszę się, że mogę nadal odpowiadać na pytania i dostarczać pomocnych informacji w katalogu 6NF, doradzać co działa, a co nie, itp., bez publikowania naszego IP (dokumentacji). Chętnie przeprowadzam również testy kwalifikacyjne dla ty.

    4 Wartość Atrybutu Entity

    Ujawnienie: Doświadczenie. Zbadałem kilka z nich, głównie szpitale i systemy medyczne. Wykonałem zadania korygujące na dwóch z nich. Początkowa dostawa przez dostawcę zagranicznego była dość adekwatna, chociaż nie była świetna, ale rozszerzenia realizowane przez lokalnego dostawcę były bałaganem. Ale nie prawie katastrofa, że ludzie napisali o RE EAV na tej stronie. Kilka miesięcy intensywnej pracy naprawił je ładnie.

    4.1 Co To Jest

    Było dla mnie oczywiste, że implementacje EAV, nad którymi pracowałem, to tylko podzbiory szóstej postaci normalnej. Ci, którzy implementują EAV, robią to, ponieważ chcą niektórych z funkcji 6NF (np. możliwość dodawania kolumn bez zmian DDL), ale nie mają wiedzy akademickiej, aby zaimplementować true 6NF, ani standardów i struktur do implementacji i administrowania nim bezpiecznie . Nawet pierwotny dostawca nie wiedział około 6NF, lub że EAV był podzbiorem 6NF, ale oni chętnie zgodzili się, gdy wskazałem im to. Ponieważ struktury wymagane do zapewnienia EAV, a nawet 6NF, sprawnie i skutecznie (katalog; widoki; automatyczne generowanie kodu) nie są formalnie identyfikowane w społeczności EAV, a brakuje ich w większości implementacji, klasyfikuję EAV jako szóstą normalną formę.

    4.2 co dokładnie w EAV jest "złe"?

    Przechodząc przez komentarze w tym i inne wątki, tak, EAV zrobione źle to katastrofa. Ważniejsze (a) są tak złe, że wydajność dostarczana w 5NF (zapomnij o 6NF) jest utracona i (B) zwykła izolacja od złożoności nie została zaimplementowana (koderzy i użytkownicy są "zmuszeni" do korzystania z uciążliwej nawigacji). A jeśli nie wdrożyliby katalogu, nie unikniemy wszelkiego rodzaju błędów, którym można zapobiec. Wszystko to może być prawdą dla złych (EAV lub innych) implementacji, ale nie ma nic wspólnego z 6NF lub EAV. Oba projekty, nad którymi pracowałem, miały dość odpowiednią wydajność (oczywiście można ją poprawić, ale nie było złej wydajności ze względu na EAV) i dobrą izolację złożoności. Oczywiście nie były one zbliżone do jakości ani wydajności moich baz danych 5NF lub mojej prawdziwej bazy danych 6NF, ale były wystarczająco uczciwe, biorąc pod uwagę poziom zrozumienia opublikowanych problemów w społeczności EAV. Były to a nie katastrofy i nonsensy podrzędne rzekomo podsłuchowe w tych stron.

    5 Nulls

    Istnieje dobrze znany i udokumentowany problem zwany problemem Null. Jest godny eseju sam w sobie. Dla tego postu wystarczy powiedzieć:

    • problemem jest tak naprawdę opcjonalna lub brakująca wartość; tutaj rozważa się projekt tabeli taki, że nie ma kolumn null vs Nullable
    • W rzeczywistości nie ma to znaczenia, ponieważ niezależnie od tego, czy używasz Nulls/No nulls/6NF, aby wykluczyć brakujące wartości, będziesz musiał kod do tego , problem dokładnie wtedy, jest Obsługa brakujących wartości, których nie można obejść
      • Z wyjątkiem oczywiście czystego 6NF, który eliminuje problem Null
      • kod do obsługi brakujących wartości pozostaje
        • Z wyjątkiem automatycznego generowania kodu SQL, heh heh
    • Nulls są złą wiadomością dla peformance, a wielu z nas zdecydowało się dekady temu nie zezwalać na Nulls w bazie danych (Nulls in przekazywanych parametrach i zestawach wyników, aby wskazać brakujące wartości, jest w porządku)
      • co oznacza zestaw substytutów Null i kolumn logicznych do wskazania brakujących wartości
    • null powoduje, że w przeciwnym razie stałe kolumny len są zmiennymi len; zmienne len kolumny nie powinny nigdy być używane w indeksach, ponieważ przy każdym dostępie do każdego wpisu indeksu, podczas przemierzania lub nurkowania, musi być wykonywane małe "rozpakowywanie".

    6 Pozycja

    I am not a zwolennik EAV lub 6NF, jestem zwolennikiem jakości i standardów. Moja pozycja to:

    1. Zawsze, na wszystkie sposoby, rób to, co robisz, zgodnie z najwyższymi standardami, o których jesteś świadomy.

    2. Normalizacja do trzeciej postaci normalnej jest minimalna dla relacyjnej bazy danych (dla mnie 5NF). Typy danych, deklaratywna referencjalna integralność, transakcje, normalizacja są podstawowymi wymaganiami bazy danych; jeśli ich brakuje, nie jest to baza danych.

      • jeśli musisz "denormalizować dla wydajności", popełniłeś poważne błędy normalizacji, Twój projekt nie został znormalizowany. Kropka. Nie "denormalizuj", wręcz przeciwnie, ucz się normalizacji i normalizacji.
    3. Nie ma potrzeby wykonywania dodatkowej pracy. Jeśli twoje wymagania mogą być spełnione z 5NF, nie wdrażaj więcej. Jeśli potrzebujesz opcjonalnych wartości lub możliwości dodawania kolumn bez zmian DDL lub całkowitej eliminacji problemu Null, zaimplementuj 6NF, tylko w tych tabele, które ich potrzebują .

    4. Jeśli to zrobisz, ze względu tylko na to, że SQL nie zapewnia odpowiedniego wsparcia dla 6NF, będziesz musiał zaimplementować:

        W 2005 roku firma została założona przez Marka i założyciela firmy, który od 2006 roku zajmuje się dystrybucją i dystrybucją artykułów reklamowych.]} W 2007 roku, w wyniku połączenia z Internetem, SQL został zastąpiony przez SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL SQL]}
      • napisz lub kup narzędzia, dzięki czemu możesz wygenerować uciążliwy SQL aby utworzyć wiersze 5NF z tabel 6NF i uniknąć pisania tego samego
      • Mierz, monitoruj, diagnozuj i ulepszaj. Jeśli masz problem z wydajnością, popełniłeś (a) błąd normalizacji lub (b) błąd kodowania. Kropka. Wykonaj kilka kroków i napraw to.
    5. Jeśli zdecydujesz się na EAV, rozpoznaj go za to, co to jest, 6NF i wdroż go prawidłowo, jak powyżej. Jeśli to zrobisz, będziesz miał udany projekt, gwarantowany. Jeśli nie, będziesz miał śniadanie dla psa, gwarantowane.

    6.1 nie ma czegoś takiego jak darmowy Lunch

    To powiedzenie zostało przywołane, ale w rzeczywistości zostało nadużywane. Sposób, w jaki faktycznie, głęboko stosuje się jest jak powyżej: jeśli chcesz korzyści z 6NF / EAV, lepiej być gotowym zbyt wykonać pracę wymaganą do jego uzyskania (katalog, standardy). Oczywiście następstwem jest to, że jeśli nie wykonasz pracy, nie dostaniesz korzyści. Nie ma "utraty" typów danych; wartość Domeny; klucze obce; kontrole; Zasady. Jeśli chodzi o wydajność, nie ma kary za wydajność dla 6NF/EAV, ale zawsze istnieje znacząca kara za wydajność za poślizg, poniżej standardu pracy.

    7 Pytanie Szczegółowe

    Wreszcie. Z należytym uwzględnieniem powyższego kontekstu i tego, że jest to mały projekt z małym zespołem, nie ma wątpliwości: {]}

    • nie używaj EAV (lub 6NF w tym przypadku)
    • nie używaj null lub Nullable columns (chyba że chcesz obalić wydajność)
    • czy używać tabeli płatności dla wspólnych kolumn płatności
    • i tabela podrzędna dla każdego typu płatności, każda z własnymi konkretnymi kolumnami
    • Wszystkie w pełni typowe i ograniczone.

    • O co chodzi z tym" another row_id"? Dlaczego niektórzy z was przyklejają IDENTYFIKATOR do wszystkiego, co się rusza, bez sprawdzania, czy to jeleń czy orzeł ? Nie.Dziecko jest dzieckiem zależnym. Relacja 1:: 1. PK dziecka jest PK rodzica, wspólna tabela płatności. Jest to zwykły klaster Supertype-Podtyp, wyróżnikiem jest PaymentTypeCode. Podtypy i supertypy są zwykłą częścią modelu relacyjnego i są w pełni zaspokajane w bazie danych, jak również w każdym dobrym narzędziu do modelowania.

      jasne, ludzie, którzy nie znają relacyjnych baz danych, myślą, że wynaleźli go 30 lat później i nadali mu zabawne nowe nazwy. Albo, co gorsza, świadomie zmieniają etykietę i twierdzą, że jest ich własna. Dopóki jakiś biedny gnojek, z odrobiną wykształcenia i dumy zawodowej, nie ujawni ignorancji lub oszustwa. Nie wiem, który to jest, ale jest to jeden z nich; Ja tylko stwierdzam fakty, które łatwo potwierdzić.

    Dzięki, że zostałaś ze mną do końca.

    A. odpowiedzi na komentarze

    A. 1 Atrybucja

    Stwierdzając, że "jestem wierny RM", a odnosząc się do "gigantów branży", założyłem, że specjaliści IT zrozumiałby, co to znaczy. Pokorne przeprosiny.

    1. nie mam osobistych, prywatnych czy specjalnych definicji. Wszystkie stwierdzenia dotyczące definicji (np. imperatywy) z:
      • normalizacja,
      • formy normalne, oraz
      • Model relacyjny.
        .
        odwołuj się do wielu oryginalnych tekstów EF Codd i CJ Date (niedostępnych za darmo w Internecie)
        .
        Najnowszy jest Dane temporalne i model relacyjny przez CJ Data, Hugh Darwen, Nikos A Lorentzos
        .
        i tylko te teksty
        .
        "stoję na ramionach olbrzymów"
        .
    2. istota, ciało, wszystkie stwierdzenia dotyczące implementacji (np. subiektywne, a pierwsza osoba) powyższe oparte są na doświadczeniu; realizacja powyższych zasad i koncepcji, jako organizacja komercyjna (konsultant lub prowadzący doradztwo), w dużych instytucjach finansowych w Ameryce i Australia, ponad 32 lata.
      • obejmuje to dziesiątki dużych zadań korygujących lub zastępujących implementacje podrzędne lub nie relacyjne.
        .
    3. problem zerowy Vis-A-vis szóstej postaci normalnej
      Ogólnodostępną białą księgę dotyczącą tytułu (nie definiuje ona samego problemu zerowego) można znaleźć na stronie:
      http://www.dcs.warwick.ac.uk/ ~ hugh / TTM / Missing-info-without-nulls. pdf .
      .
      Definicja 6NF w skrócie (znaczące dla tych doświadczonych z innymi NFs), można znaleźć na p6

    A. 2 Dowody Potwierdzające

    1. jak stwierdzono na początku, celem tego postu jest przeciwdziałanie dezinformacji, która jest szerzona w tej społeczności, jako usługa dla wspólnoty.
    2. dowody potwierdzające oświadczenia złożone re implementacja powyższych zasad, mogą być dostarczone, jeśli i kiedy określone oświadczenia są zidentyfikowane; i w tym samym stopniu, że podobnie świadczy się o błędnych wypowiedziach zamieszczonych przez innych, na które ten post jest odpowiedzią. Jeśli będzie walka z bułką, upewnijmy się, że pole gry jest na poziomie
    3. Oto kilka dokumentów, które mogę natychmiast położyć ręce, aby rozpocząć (jestem na stanowisku w NZ, dostarczy więcej w ciągu kilku dni, nazwy klientów muszą być zaciemnione).

      A. Duży Bank
      Jest to najlepszy przykład, jak to zostało podjęte dla wyraźnie powody w tym poście i cele zostały zrealizowane. Mieli budżet na Sybase IQ (produkt DW), ale raporty były tak szybkie, gdy zakończyliśmy projekt, nie potrzebowali go. Statystyki analityczne handlu to moje 5NF plus pivoting extensions, które okazały się być 6NF, opisane powyżej. Myślę, że wszystkie pytania zadawane w komentarzach zostały udzielone w doc, z wyjątkiem:
      - liczba wierszy:
      - stara baza danych jest nieznana, ale można ją ekstrapolować z drugiej Statystyki
      - nowa baza danych = 20 tabel powyżej 100M, 4 tabele powyżej 10B.

      B. mały Instytut finansowy CZ. A
      część B - mięso
      część C - diagramy odniesienia
      część D - dodatek, audyt indeksów Przed/Po (1 wiersz na indeks)
      Zwróć uwagę na cztery dokumenty; czwarty tylko dla tych, którzy chcą sprawdzić szczegółowe zmiany indeksu. Używali aplikacji innej firmy, której nie można było zmienić ponieważ lokalny dostawca był poza rynkiem, plus 120% rozszerzeń, które mogli, ale nie chcieli, zmienić. Zostaliśmy wezwani, ponieważ uaktualniono je do nowej wersji Sybase, która była znacznie szybsza, co przesunęło różne progi wydajności, co spowodowało dużą liczbę impasów. Tutaj Znormalizowaliśmy absolutnie wszystko na serwerze z wyjątkiem Modelu db, z celem (gwarantowanym wcześniej) wyeliminowania impasów (przepraszam, Nie będę tego tutaj tłumaczył: ludzie kto kłóci się o problem "denormalizacji" , będzie w różowym wydaniu o tym). Zawierał on odwrócenie "dzielenia tabel na archiwum db dla wydajności", co jest tematem kolejnego postu(tak, nowy pojedynczy stół działał szybciej niż dwa rozlane). To ćwiczenie dotyczy również MS SQL Server [insert rewrite version].

      C. Yale New Haven Hospital
      To Yale School Of Medicine, ich Szpital Nauczycielski. Wspieram ich od lat. Aplikacja innej firmy na górze Sybase. Problem ze statystykami polega na tym, że w 80% przypadków zbierali migawki tylko w wyznaczonych godzinach testowych, ale nie ma spójnej historii, więc nie ma "przed obrazem", z którym można porównać nasze nowe spójne statystyki. Nie znam żadnego innego co, który może uzyskać wewnętrzne statystyki Unixa i Sybase na tych samych wykresach, w sposób zautomatyzowany . Teraz sieć jest progiem(zaufaj czytelnikowi, że to dobrze).

    Just na początek coś, co zostało zatwierdzone do publikacji. Więcej później. Ok, weźmy jakieś dowody na poparcie tezy, że "'denormalizacja' poprawia wydajność " itp. Twoja kolej.

    A. 3 Długość

      Nie przepraszam za Długość ani za skondensowaną naturę. Osoby z krótką uwagą (bez urazy, to jest rzeczywistość w dzisiejszych czasach), lub którzy nie są zaznajomieni z relacyjną technologią lub terminologią, powinny odwoływać się do tekstów źródłowych lub do zwolenników tej technologii.
    1. z definicji wyklucza to Wiki, a każdy, kto oczernia tę technologię, np. plakaty, na które ten post jest odpowiedzią. Słoń nie może zdefiniować Gazeli, a jeśli postulują o życiu Gazel, nie powinniśmy ich słuchać.
     29
    Author: PerformanceDBA,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2010-11-25 02:05:29

    Moją zasadą nr 1 jest nie przeprojektowywać czegoś bez powodu. Więc wybrałbym opcję 1, ponieważ jest to twój obecny projekt i ma udokumentowaną historię działania.

    Zamiast tego poświęć czas na przeprojektowanie nowych funkcji.

     2
    Author: Andomar,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2010-10-29 21:48:25

    Gdybym projektował od podstaw, wybrałbym numer dwa. Zapewnia elastyczność, której potrzebujesz. Jednak z numerem 1 już na miejscu i działa, a to jest takemting raczej centralną dla całej aplikacji, prawdopodobnie byłbym ostrożny dokonywania dużych zmian projektu bez dobrego pojęcia o tym, co dokładnie zapytania, przechowywane procs, widoki, UDFs, raporty, import itp trzeba by zmienić. Gdyby to było coś, co mógłbym zrobić przy stosunkowo niskim ryzyku (IOD testowania alrady w miejscu.) I might go dla zmiany do rozwiązania 2 inaczej może być wprowadzając nowe gorsze błędy.

    Pod żadnym pozorem nie użyłbym do czegoś takiego tabeli podsłuchów. Są okropne dla zapytań i wydajności, a elastyczność jest zbyt przereklamowana(zapytaj użytkowników, czy wolą być w stanie dodawać nowe typy 3-4 razy w roku bez zmiany programu kosztem codziennej wydajności).

     2
    Author: HLGEM,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2010-10-29 21:59:22

    Na pierwszy rzut oka wybrałbym opcję 2 (lub 3): jeśli to możliwe, uogólnić. Opcja 4 nie jest zbyt relacyjna i sprawi, że Twoje zapytania będą złożone. Kiedy konfrontuję się z tymi pytaniami, zazwyczaj konfrontuję te opcje z "przypadkami użycia":
    - jak zachowuje się projekt 2/3, kiedy to czy ta operacja ?

     0
    Author: Patrick Honorez,
    Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
    2010-10-29 21:53:54