Czy normalizacja bazy danych jest martwa? [Zamknięte]

Wychowałem się w starej szkole - gdzie nauczyliśmy się projektować schemat bazy danych PRZED warstwą biznesową aplikacji (lub używając OOAD do wszystkiego innego). Byłem całkiem dobry w projektowaniu schematów (IMHO :) i znormalizowałem tylko, aby usunąć niepotrzebną redundancję, ale nie tam, gdzie wpłynęło to na szybkość, tj. Jeśli złączenia były hitem wydajności, redundancja pozostała na miejscu. Ale przeważnie tak nie było.

Wraz z pojawieniem się niektórych środowisk ORM, takich jak ActiveRecord Ruby lub ActiveJDBC (i kilka innych, których nie pamiętam, ale jestem pewien, że jest ich mnóstwo), wydaje się, że wolą mieć klucz zastępczy dla każdej tabeli, nawet jeśli niektóre mają klucze podstawowe, takie jak „email” - całkowite zerwanie 2NF. Ok, nie rozumiem zbyt wiele, ale działa mi to na nerwy (prawie), gdy niektóre z tych ORM (lub programistów) nie potwierdzają 1-1 lub 1-0 | 1 (tj. 1 do 0 lub 1). Zastrzegają, że po prostu lepiej mieć wszystko jako jeden duży stół, bez względu na to, czy ma mnóstwo nulls „dzisiejszych systemów to da”, to komentarz, który słyszę częściej.

Zgadzam się, że ograniczenia pamięci miały bezpośrednią korelację z normalizacją (są też inne korzyści :) ale w dzisiejszych czasach przy taniej pamięci i maszynach czterordzeniowych czy koncepcja normalizacji DB została pozostawiona tekstom? Jako DBA nadal ćwiczysz normalizację do 3NF (jeśli nie BCNF :)? Czy to ma znaczenie? Czy projektowanie „brudnego schematu” jest dobre dla systemów produkcyjnych? Jak należy argumentować za normalizacją „jeśli” jest nadal aktualna.

( Uwaga: nie mówię o schematach gwiazdy / płatka śniegu w magazynie danych, które mają nadmiarowość jako część / potrzebę projektu, ale systemy komercyjne z bazą danych zaplecza, na przykład StackExchange)

Jednym z powodów normalizacji jest usunięcie anomalii modyfikacji danych
ORM zwykle tego nie obsługują.

Mam wiele przykładów baz danych zaprojektowanych przez Hibernata, które łamią tę zasadę:

• wzdęty (ciąg powtórzony ponad 100 milionów milionów wierszy)
• brak tabel przeglądowych (patrz wyżej)
• brak DRI (ograniczenia, klucze)
• indeksy klastrowe varchar
• niepotrzebne tabele linków (np. wymuszanie 1..0: 1, gdy wystarczająca będzie zerowa kolumna FK)

Najgorsze, co widziałem, to baza danych MySQL o pojemności 1 TB, która z tego powodu była o 75–80% za duża

Sugeruję również, że stwierdzenie „dzisiejsze systemy potrafią sobie z tym poradzić” jest prawdziwe w przypadku większości systemów Myszki Miki. Podczas skalowania dzisiejsze systemy nie będą.

W powyższym przykładzie nie było żadnej troski o refaktoryzację, zmianę kluczy lub naprawę danych: po prostu narzekaj na tempo wzrostu bazy danych i brak możliwości zbudowania znaczącej DW

wygląda na to, że wolą mieć klucz zastępczy dla każdego stołu, nawet jeśli niektóre mają klucze podstawowe, takie jak „e-mail” - całkowicie niszcząc 2NF.

Klucze zastępcze nie psują 2NF. 2NF mówi „Jeśli kolumna jest zależna tylko od części klucza wielowartościowego, usuń tę kolumnę do osobnej tabeli”.

Zastrzegają, że po prostu lepiej mieć wszystko jako jeden duży stół, bez względu na to, czy ma mnóstwo zer

Posiadanie kilku kolumn w jednej tabeli jest ważne, o ile przestrzegane są reguły normalizacji. Scalanie tabel bez analizy nie jest poprawne, jeśli chcesz czerpać korzyści z SQL i normalizacji.

Zgadzam się, że ograniczenia pamięci miały bezpośrednią korelację z normalizacją. Relacja Formy normalne jest pojęciem matematycznym i nie ma nic wspólnego z pamięcią.

Normalizacja ma na celu nie tylko oszczędność pamięci lub dysku, ale także integralność. W końcu jest to koncepcja matematyczna niezależna od sprzętu.

Prosty przykład: powiedz, że zachowujesz informacje o szkole jako:

Rec 1: North Ridge High School, Kalifornia, USA

Rec 2: South Toronto Braves High School, Ontario, Kanada

Jeśli zapytasz swój system, gdzie jest Ontario, możesz dowiedzieć się, że jest on w Kanadzie. Kilka dni później usuwasz drugi wiersz i zadajesz systemowi to samo pytanie i nic nie dostajesz. W tym przykładzie, bez względu na to, ile miejsca na dysku, pamięci lub procesora, nie otrzymasz odpowiedzi.

Jest to jedna anomalia normalizująca relacje, które zapobiegają.

Edytuj: Zmieniono słowo Toronto na Ontario zgodnie z komentarzem poniżej.

Im więcej rzeczy się zmienia, tym bardziej pozostają one takie same. Zawsze byli leniwi programiści, którzy skracają rogi lub po prostu nie znają lub nie chcą stosować najlepszych praktyk. Dużo czasu mogą sobie z tym poradzić w mniejszych aplikacjach.

Kiedyś blokował struktury danych inspirowane COBOL-em we wczesnym RDBMS lub okropny bałagan, którym był dBase. Teraz są ORM i „Code-First”. W końcu są to po prostu sposoby, w jakie ludzie próbują znaleźć srebrną kulę uzyskania działającego systemu bez „marnowania” czasu na intensywne myślenie o tym, co chcesz i musisz zrobić. Pośpiech zawsze był problemem i zawsze będzie problemem.

Dla tych, którzy mają dobry rozsądek (i powodzenia) poświęcić czas na prawidłowe zaprojektowanie, model danych zawsze będzie najbardziej logicznym miejscem do rozpoczęcia. W bazie danych znajdują się informacje o rzeczach (materialnych i niematerialnych), o które dba Twoja firma. Co twoje troski firmy o zmianach znacznie wolniej niż w jaki sposób Twoja firma prowadzi działalność. To dlatego baza danych jest ogólnie znacznie bardziej stabilna niż kod.

Baza danych jest właściwą podstawą każdego systemu, a poświęcenie czasu na prawidłowe położenie fundamentów nieuchronnie przyniesie korzyści w dłuższej perspektywie. Oznacza to, że normalizacja zawsze będzie ważnym, użytecznym krokiem dla każdej aplikacji typu OLTP.

Zgadzam się, że ograniczenia pamięci miały bezpośredni związek z normalizacją ...

Ograniczenia pamięci wciąż mają znaczenie. Ilość nie jest problemem, prędkość jest.

• Procesory nie są teraz szybsze (otrzymujemy więcej rdzeni, a nie cykli na sekundę)
• Współczesne architektury procesorów próbują pokonać ograniczenie prędkości, zapewniając oddzielną pamięć dla każdego procesora ( NUMA ).
• Rozmiary pamięci podręcznej nie rosną w tempie porównywalnym z pamięcią główną.
• Przepustowość pamięci nie jest tak wysoka, jak większość ludzi się spodziewa. QPI wynosi około 25 GB / s.

Część tego gruntu została omówiona w Kiedy używać TINYINT zamiast INT? które mogą ci się przydać. Sugerowałbym także podążanie za wybrykami @ThomasKejser ( blog ) z zespołu SQLCAT, ponieważ mają oni tendencję do zwiększania wydajności bazy danych. Niedawny post na temat wpływu pamięci podręcznej procesora i wzorców dostępu do pamięci oraz prezentacji SQLBits w modelowaniu relacyjnym dla ekstremalnej skali DW są dobrymi przykładami.

Moim zdaniem nadal chodzi tylko o równowagę między normalizacją a de-normalizacją . Całkowicie się zgadzam, że frameworki ORM są po prostu podejściem do robienia rzeczy, ale nie sądzę, że to te frameworki powodują trend normalizacji .

wciąż jest to debata, w której zależy Ci na wydajności czasu lub na wydajności przestrzeni. W momencie, gdy pojawia się teoria relacyjnych baz danych, miejsce na dysku jest drogie, ludzie oczywiście nie chcą wydawać na to tyle pieniędzy, dlatego w tym czasie relacyjne bazy danych są twarde wśród przeciwności losu

Teraz dni są zupełnie inne, przechowywanie jest bardzo, bardzo tanie. Tak więc oczywiście możemy tolerować większą nadmiarowość w porównaniu do dawnych czasów, dlatego DLACZEGO pojawiło się podejście BIG_TABLE. w celu poszukiwania większej wydajności czasowej należy poświęcić wydajność przestrzeni.

Ale podejście Big-table również nie jest końcem historii, nadal pozostaje równowaga między czasem i przestrzenią, pod względem ilości danych PB do zarządzania, niektórzy deweloperzy również zaczęli szukać równowagi z powrotem do wydajności przestrzeni, dlatego istnieje wykonywane są prace nad normalizacją niektórych danych w strukturach typu BIG-TABLE.

Jednym słowem, podejście normalizacyjne nie jest zdecydowanie martwe, ale w porównaniu do dawnych czasów jest zdecydowanie pomijane.

CJ Date odpowiada na twoje pytanie tutaj - film normalizacyjny (wstępny) jest bezpłatny.

http://shop.oreilly.com/product/0636920025900.do

Krótka odpowiedź: normalizacja jest matematycznie poprawnym sposobem robienia rzeczy. Jeśli nie normalizujesz się prawidłowo, Twój model danych jest po prostu niepoprawny.