Odpowiedzi:
Powinieneś iść tak daleko, jak powinieneś i nie dalej. Oczywiście. ~ Problemem może być to, że to trochę sztuka, i dlatego nie jest to czysta nauka.
Naszym głównym produktem jest system analizy i raportowania, dlatego w tym zakresie mamy sporo szczegółowych zapisów. Początkowo zaprojektowaliśmy go z dużą liczbą złączeń na wspólnym identyfikatorze dla niektórych rekordów potomnych, ale okazało się, że jeśli zdenormalizujemy kilka pól, moglibyśmy wyciąć DUŻĄ liczbę złączeń i moglibyśmy usunąć wiele problemów z wydajnością.
Ale wiedzieliśmy to tylko dlatego, że 1) stworzyliśmy „znormalizowany” projekt, 2) zaczęliśmy go używać, 3) profilowaliśmy rzeczywistą wydajność po setkach milionów wierszy w dziesiątkach tabel.
Ostateczna historia jest taka, że dopóki się nie sprofilowaliśmy, nie mogliśmy mieć pewności, co dla nas zadziała. Podobał nam się pomysł normalizacji, abyśmy mogli łatwiej aktualizować, ale ostatecznie decydująca była rzeczywista wydajność. Oto moja rada dla Ciebie: profil, profil, profil.
in ('forgiven','pardoned');): p
Normalizacja jest celem tylko wtedy, gdy obsługuje model danych wystarczająco dobrze, aby to uzasadnić. Ma on stanowić przewodnik umożliwiający wzrost, zarządzanie i utrzymanie. Pamiętaj, że książka o normalizacji ani jej autor nie zamierzają budować ani utrzymywać bazy danych ani aplikacji.
Dobra lektura na temat „zbyt dużej normalizacji” znajduje się tutaj.
I tak, zbyt duża normalizacja może mieć wpływ na wydajność. Byłoby to głębsze przechodzenie do stołu, aby podnieść takie rzeczy, jak tabele wskaźników statusu, gdy zostały one wyciągnięte do osobnego stołu. Niektórzy powiedzą, że jest to zwykle zanegowane w szybkości aktualizacji (zmiana tekstu statusu z „Dobry” na „DOBRY” lub coś podobnego) lub w utrzymywalności.
Polecam lekturę następującego dodatku znajdującego się w kilku najnowszych książkach Chrisa Date :
Normalizacja daleka jest od bycia panaceum, co możemy łatwo zobaczyć, zastanawiając się, jakie są jej cele i jak dobrze je mierzy ...
Muszę wyjaśnić, że nie chcę, aby moje komentarze w tej sekcji były postrzegane jako jakikolwiek rodzaj ataku. Jestem przekonany, że cokolwiek mniej niż w pełni znormalizowany projekt jest zdecydowanie przeciwwskazane ...
Myślę, że równie ważne jest przyjrzenie się jawnie dodanym denormalizacjom, albo dodanym wartościom zagregowanym, albo niektórym polom z tabeli wzorcowej skopiowanej do kopii szczegółowej.
Argument ten jest głównie argumentem wydajności.
Jeśli to zrobisz, wymusisz, aby te pola były aktualizowane przez wyzwalacze, i to od bazy danych zależy, czy będą spójne.
Całkowicie zgadzam się z @jcolebrand. Projektując model aplikacji, należy znormalizować wszystko, co możesz. Ale powinieneś profilować zapytania zbudowane w twoim modelu, szczególnie te często wykonywane.
Moje własne doświadczenie: atrybuty, które wymagały dwóch złączeń (co oznacza, że dołączyły trzy tabele), będą głównie świnią wydajności. Co gorsza, jest wykorzystywany w transakcjach internetowych. Denormalizuję atrybut, więc potrzebuje tylko jednego sprzężenia i poprosił programistę o dostosowanie aplikacji do zapytania i zaktualizowanie atrybutu. Teraz działa znacznie lepiej ...
Innymi słowy, należy zrównoważyć normalizację z wydajnością.