Normalizáció a valós világban
Az adatbázis-normalizálás az alkalmazások fejlesztésének szent tehenete. Minden olyan egyetemi programozási kurzus, amelyet megtalált vagy könyv olvasott, valószínűleg prédikálja az adatbázisok normalizálásának fontosságát.
Itt az ideje, hogy megkérdőjelezzük az igazságosságot. Néha rendben van az adatbázis kicserélése!
Mikor kell normalizálni?
Az adatbázisok normalizálása védi az adatok integritását. Számos esetben ez egy jó ötlet, és minden normalizálási elképzelést meg kell kezdenie bármely adatbázis-tervezési törekvésnek. Ha tudod normalizálni az adatbázist, menj rá! Valójában, itt van néhány gyakorlati tanács, hogyan lehet normalizálni adatbázisát ezen az oldalon:
- Adatbázis behelyezése az első normál űrlapba (1NF)
- Adatbázis elhelyezése a második normál formában (2NF)
- Adatbázis harmadik normál formában (2NF)
A lényeg az, hogy normalizálnia kell az adatbázisát, hacsak nem igazán jó oka van ennek. A normalizálás általában hangtervezés. Csökkenti az elbocsátott információkat, optimalizálja a teljesítményt és csökkenti annak valószínűségét, hogy adatintegritási problémái jelentkezhetnek, amelyek ugyanazokból az adatokból fakadnak, amelyek az adatbázis különböző sarkában vannak.
Néhány jó ok arra, hogy ne normalizálják
Ez azt jelenti, hogy van néhány jó oka annak, hogy nem normalizálják adatbázisát. Nézzünk néhányat:
- A csatlakozások drágák . Az adatbázisok normalizálása gyakran sok táblát hoz létre. Valójában könnyedén fel tudsz lépni azzal, amiről úgy gondolod, hogy egy egyszerű lekérdezés, amely öt vagy tíz asztalra terjed ki. Ha valaha próbálkozott egy ötasztalos csatlakozással, akkor tudod, hogy elvileg működik, de a gyakorlatban lelassul. Ha olyan webes alkalmazást építesz, amely a nagy táblákkal szemben többszörös összekapcsolódási lekérdezésekre támaszkodik, talán úgy gondolja, hogy "Ha csak ez az adatbázis nem normalizálódik!" Ha ezt a gondolatot hallja a fejedben, akkor jó ideje fontolja meg a denormalizációt. Ha az adott lekérdezés által használt összes adatot egyetlen táblázatba beágyazhatja anélkül, hogy valóban veszélybe sodorja az adatok integritását, menjen rá! Legyetek lázadók és denormalizálják adatbázisát. Nem nézel vissza!
- A normalizált tervezés nehéz . Ha komplex adatbázis sémával dolgozik, valószínűleg találja magát a fejét az asztalhoz ütközve a normalizáció bonyolultsága miatt. Egyszerű szabályként, ha egész nap arra törekszel, hogy kitaláljuk, hogyan mozoghatnánk a negyedik normális alakra, akkor túlságosan normalizálhatnánk. Lépj vissza, és kérdezd meg magadtól, hogy valóban érdemes folytatni.
- Gyors és piszkos legyen gyors és piszkos . Ha csak prototípust fejlesztesz, csak csinálj gyorsan. Igazán. Ez rendben van. A gyors alkalmazásfejlesztés néha fontosabb, mint az elegáns formatervezés. Ne felejtse el, hogy menjen vissza, és vigyázzon alaposan a formatervezésre, miután készen áll a prototípusfázisra való áttérésre. A gyors és piszkos adatbázis-tervezésért fizetett ár az, hogy lehet, hogy el kell dobnia, és el kell kezdenie, amikor eljön az ideje, hogy felépítse a termelést.
- Ha NoSQL adatbázist használ , a hagyományos normalizáció nem kívánatos. Ehelyett tervezze meg adatbázisát a BASE modell segítségével, amely sokkal megbocsátható. Ez akkor hasznos, ha nem strukturált adatokat, például e-maileket, képeket vagy videókat tárol.
Néhány óvatossági szava
Az adatbázis normalizálása általában jó ötlet. Meg kell próbálnod követni a normalizáció elveit, ha ésszerűnek tűnik. De ha minden mutató arra utal, hogy a normalizálás túlságosan bonyolult ahhoz, hogy megvalósuljon, fontolja meg azt a megközelítést, amely a munkát végzi, miközben védi adatait.
Végül - ha úgy döntesz, hogy elveszíted a normalizálás szabályait, vigyen magaddal az adatbázis integritásának érvényesítésére. Ha felesleges információkat tárol, tegye be az aktiválókat és egyéb vezérlőket, hogy megbizonyosodjon arról, hogy az adatok konzisztensek maradjanak.