Et filosofisk svar:Suboptimale (relationelle) databaser er fyldt med indsættelse, opdatering og sletning af anomalier. Disse fører alle til inkonsistente data, hvilket resulterer i dårlig datakvalitet. Hvis du ikke kan stole på nøjagtigheden af dine data, hvad hjælper det så? Spørg dig selv dette:Vil du have de rigtige svar langsommere, eller vil du have de forkerte svar hurtigere?
Som en praktisk sag:få det rigtigt, før du får det hurtigt. Vi mennesker er meget dårlige til at forudsige, hvor flaskehalse vil opstå. Gør databasen fantastisk, mål ydeevnen over en anstændig periode, og beslut derefter, om du skal gøre den hurtigere. Før du denormaliserer og ofrer nøjagtighed, prøv andre teknikker:kan du få en hurtigere server, forbindelse, db-driver osv.? Kan lagrede procedurer fremskynde tingene? Hvordan er indeksene og deres fyldningsfaktorer? Hvis disse og andre præstations- og tuningteknikker ikke gør tricket, skal du først overveje denormalisering. Mål derefter ydeevnen for at verificere, at du fik den stigning i hastigheden, som du "betalte for". Sørg for, at du udfører optimering, ikke pessimisering.
[rediger]
A:Selvfølgelig.
- Lav en sikkerhedskopi.
- Lav endnu en sikkerhedskopi til en anden enhed.
- Opret nye tabeller med kommandoer af typen "vælg i ny tabel fra gammel tabel...". Du skal lave nogle joinforbindelser for at kombinere tidligere adskilte tabeller.
- Slip de gamle tabeller.
- Omdøb de nye tabeller.
MEN ... overvej en mere robust tilgang:
Opret nogle visninger på dine fuldt normaliserede tabeller lige nu. Disse synspunkter (virtuelle tabeller, "vinduer" på data... spørg mig, hvis du vil vide mere om dette emne) ville have den samme definerende forespørgsel som trin tre ovenfor. Når du skriver din applikation eller DB-lagslogik, skal du bruge visningerne (i det mindste til læseadgang; opdaterbare visninger er... ja, interessant). Så hvis du denormaliserer senere, skal du oprette en ny tabel som ovenfor, slippe visningen, omdøbe den nye basistabel uanset visningen. Din applikation/DB-lag kender ikke forskellen.
Der er faktisk mere til dette i praksis, men dette burde få dig i gang.