Odpowiedź filozoficzna:Suboptymalne (relacyjne) bazy danych są pełne anomalii wstawiania, aktualizowania i usuwania. To wszystko prowadzi do niespójnych danych, co skutkuje słabą jakością danych. Jeśli nie możesz zaufać dokładności swoich danych, co z tego? Zadaj sobie następujące pytanie:Czy chcesz, aby prawidłowe odpowiedzi były wolniejsze, czy chcesz, aby nieprawidłowe odpowiedzi były szybsze?
Z praktycznego punktu widzenia:zrób to dobrze, zanim zrobisz to szybko. My, ludzie, jesteśmy bardzo źli w przewidywaniu, gdzie wystąpią wąskie gardła. Spraw, aby baza danych była świetna, mierz wydajność przez przyzwoity okres czasu, a następnie zdecyduj, czy musisz ją przyspieszyć. Zanim dokonasz denormalizacji i poświęcisz dokładność, wypróbuj inne techniki:czy możesz uzyskać szybszy serwer, połączenie, sterownik bazy danych itp.? Czy procedury składowane mogą przyspieszyć działanie? Jak wyglądają indeksy i ich współczynniki wypełnienia? Jeśli te i inne techniki wydajności i strojenia nie załatwią sprawy, dopiero wtedy rozważ denormalizację. Następnie zmierz wydajność, aby sprawdzić, czy uzyskałeś wzrost prędkości, za który „zapłaciłeś”. Upewnij się, że przeprowadzasz optymalizację, a nie pesymizację.
[edytuj]
O:Jasne.
- Zrób kopię zapasową.
- Utwórz kolejną kopię zapasową na innym urządzeniu.
- Twórz nowe tabele za pomocą poleceń typu „wybierz do nowej tabeli ze starej tabeli...”. Będziesz musiał wykonać kilka złączeń, aby połączyć wcześniej odrębne tabele.
- Upuść stare tabele.
- Zmień nazwy nowych tabel.
ALE ... rozważ bardziej solidne podejście:
Utwórz teraz kilka widoków na w pełni znormalizowanych tabelach. Te widoki (wirtualne tabele, „okna” na dane... zapytaj mnie, czy chcesz dowiedzieć się więcej na ten temat) miałyby to samo zapytanie definiujące, co krok trzeci powyżej. Kiedy piszesz swoją aplikację lub logikę warstwy DB, używaj widoków (przynajmniej do odczytu; widoki, które można aktualizować są… cóż, interesujące). Następnie, jeśli później denormalizujesz, utwórz nową tabelę jak powyżej, upuść widok, zmień nazwę nowej tabeli bazowej na dowolny widok. Twoja aplikacja/warstwa DB nie zauważy różnicy.
W praktyce jest tego więcej, ale to powinno Cię zacząć.
