Een filosofisch antwoord:suboptimale (relationele) databases zitten vol met invoeg-, update- en verwijderafwijkingen. Deze leiden allemaal tot inconsistente gegevens, wat resulteert in een slechte gegevenskwaliteit. Als u de nauwkeurigheid van uw gegevens niet kunt vertrouwen, wat heeft u eraan? Stel jezelf de volgende vraag:wil je de juiste antwoorden langzamer of wil je de verkeerde antwoorden sneller?
Praktisch gezien:zorg dat je het goed hebt voordat je het snel hebt. Wij mensen zijn erg slecht in het voorspellen waar knelpunten zullen optreden. Maak de database geweldig, meet de prestaties over een behoorlijke periode en beslis vervolgens of je het sneller moet maken. Probeer andere technieken voordat u denormaliseert en de nauwkeurigheid opoffert:kunt u een snellere server, verbinding, db-stuurprogramma, enz. krijgen? Kunnen opgeslagen procedures de zaken versnellen? Hoe zijn de indexen en hun vulfactoren? Als die en andere prestatie- en afstemmingstechnieken niet werken, overweeg dan pas denormalisatie. Meet vervolgens de prestaties om te controleren of u de snelheidstoename kreeg waarvoor u "betaalde". Zorg ervoor dat u optimalisatie uitvoert, geen pessimatie.
[bewerken]
een:Zeker.
- Maak een back-up.
- Maak nog een back-up naar een ander apparaat.
- Maak nieuwe tabellen met "selecteer in nieuwe tabel van oude tabel..." commando's. U moet enkele samenvoegingen doen om eerder verschillende tabellen te combineren.
- Laat de oude tabellen vallen.
- Hernoem de nieuwe tabellen.
MAAR ... overweeg een robuustere aanpak:
Maak nu enkele weergaven op uw volledig genormaliseerde tabellen. Die weergaven (virtuele tabellen, "vensters" op de gegevens... vraag me of je meer wilt weten over dit onderwerp) zouden dezelfde bepalende vraag hebben als stap drie hierboven. Wanneer u uw toepassing of DB-laaglogica schrijft, gebruik dan de views (tenminste voor leestoegang; bij te werken views zijn... nou ja, interessant). Als u later denormaliseert, maakt u een nieuwe tabel zoals hierboven, laat u de weergave vallen en hernoemt u de nieuwe basistabel, ongeacht de weergave. Je applicatie/DB-laag zal het verschil niet weten.
In de praktijk komt hier meer bij kijken, maar dit zou je op weg moeten helpen.