Filosofická odpověď:Suboptimální (relační) databáze jsou plné anomálií vkládání, aktualizace a mazání. To vše vede k nekonzistentním datům, což má za následek nízkou kvalitu dat. Pokud nemůžete věřit přesnosti svých údajů, k čemu to je? Zeptejte se sami sebe:Chcete správné odpovědi pomaleji, nebo chcete špatné odpovědi rychleji?
Prakticky:udělejte to správně, než to dostanete rychle. My lidé jsme velmi špatní v předpovídání, kde se objeví úzká hrdla. Udělejte databázi skvělou, měřte výkon za slušnou dobu a pak se rozhodněte, zda ji potřebujete zrychlit. Než začnete denormalizovat a obětovat přesnost, vyzkoušejte jiné techniky:můžete získat rychlejší server, připojení, ovladač db atd.? Mohly by uložené procedury věci urychlit? Jak jsou na tom indexy a jejich faktory plnění? Pokud tyto a další techniky výkonu a ladění nepomohou, teprve potom zvažte denormalizaci. Poté změřte výkon, abyste ověřili, že jste dosáhli zvýšení rychlosti, za které jste „zaplatili“. Ujistěte se, že provádíte optimalizaci, nikoli pesimizaci.
[upravit]
A:Jasně.
- Proveďte zálohu.
- Proveďte další zálohu do jiného zařízení.
- Vytvářejte nové tabulky pomocí příkazů typu „select into newtable from oldtable...“. Chcete-li kombinovat dříve odlišné tabulky, budete muset provést několik spojení.
- Zrušte staré tabulky.
- Přejmenujte nové tabulky.
ALE ... zvažte robustnější přístup:
Vytvořte některá zobrazení na plně normalizovaných tabulkách právě teď. Tyto pohledy (virtuální tabulky, "okna" s daty... zeptejte se mě, jestli se chcete o tomto tématu dozvědět více) by měly stejný definující dotaz jako krok tři výše. Když píšete svou aplikaci nebo logiku na úrovni DB, používejte pohledy (alespoň pro přístup ke čtení; aktualizovatelné pohledy jsou... no, zajímavé). Pokud potom denormalizujete později, vytvořte novou tabulku jako výše, zrušte pohled a přejmenujte novou základní tabulku bez ohledu na to, jaký pohled byl. Vaše aplikace/vrstva DB nepozná rozdíl.
Ve skutečnosti je toho v praxi více, ale toto by vás mělo nastartovat.