Normaalimine reaalses maailmas
Andmebaasi normaliseerimine on üks rakenduste arendamise püha lehmast. Iga bakalaureuse programmeerimise kursus, mille olete loonud või broneerinud, on tõenäoliselt juttu andmebaaside normaliseerimise olulisusest.
On aeg vaidlustada seda tõde. Mõnikord on teie andmebaasi denormaliseerimine õige!
Millal peaksite normaalseks saama?
Andmebaasi normaliseerimine kaitseb teie andmete terviklikkust. Paljudel juhtudel on see suurepärane mõte ja peaksite alustama andmebaasi projekteerimise püüdlusi normaalseks muutmisel. Kui saate oma andmebaasi normaliseerida, mine seda! Tegelikult on siin mõned praktilised nõuanded selle kohta, kuidas teie saidil oma andmebaasi normaliseerida:
- Andmebaasi asetamine esimeses normaalses vormis (1NF)
- Andmebaasi asetamine teises tavalises vormis (2NF)
- Andmebaasi asetamine kolmandasse normaalsesse vormi (2NF)
Lõpptulemus on see, et peaksite oma andmebaasi normaliseerima, kui teil pole tõelist põhjust seda mitte teha. Normaliseerimine on tavaliselt hea disaini tava. See vähendab koondatut teavet, optimeerib toimivust ja vähendab tõenäosust, et teil on andmete terviklikkusprobleemid, mis võivad tuleneda teie andmebaaside erinevate nurkade sulgemisest.
Mõned head põhjused ei normaliseeri
Siiski on mõned põhjused, mis ei võimalda teie andmebaasi normaliseerida. Vaatame mõningaid:
- Liitumised on kallid . Teie andmebaasi normaliseerimine tähendab sageli palju tabelite loomist. Tegelikult võite kergesti lõpetada selle, mis teie arvates peaks olema lihtne päring, mis hõlmab viit või kümmet tabelit. Kui olete kunagi proovinud viis lauda ühendada, teate, et see toimib põhimõtteliselt, kuid praktikas on see praktiliselt aeglane. Kui teete veebiprojekti, mis tugineb suurte tabelitega seotud mitmekordse liitumisega päringutele, võite tunda end mõttelda: "Kui ainult see andmebaas ei normaliseeri!" Kui kuulete seda mõtet peas, on hea aeg kaaluge denormaliseerumist. Kui saate selle päringuga kõik andmed ühe tabelisse kinni hoida, ilma et see kahjustaks teie andmete terviklikkust, mine seda! Ole mässulistega ja oma andmebaasi denormaliseerige. Sa ei vaata tagasi!
- Normaliseeritud disain on raske . Kui te töötate koos kompleksse andmebaasiklaasiga, siis tõenäoliselt leiaksite end peksmise vastu tabeli peale normaliseerumise keerukuse. Lihtsa rusikareegelina, kui te kulutate kogu päeva, et mõista, kuidas neljandasse tavalisse vormi liigutada, võite normaliseeruda liiga kaugele. Astuge tagasi ja küsige endalt, kas see on tõesti väärt jätkamist.
- Kiire ja määrdunud peaks olema kiire ja määrdunud . Kui te lihtsalt arendate prototüüpi, tehke kõik, mis kiiresti töötab. Tõesti See on korras. Kiire rakenduste arendamine on mõnikord tähtsam kui elegantne disain. Ärge unustage, et pöörduge tagasi ja uurige oma disaini hoolikalt, kui olete valmis prototüpiseerimisetapist kaugemale minema. Kiire ja räpane andmebaasi disaini eest makstav hind on see, et peate selle ära viskama ja alustama, kui on aeg ehitada tootmiseks.
- Kui kasutate NoSQL-i andmebaasi , pole traditsiooniline normaliseerumine soovitav. Selle asemel disainige oma andmebaas BASE- mudeli abil, mis on palju andekam. See on kasulik, kui hoiate struktureerimata andmeid, näiteks e-kirju, pilte või videoid.
Mõned sõnad ettevaatlik
Andmebaasi normaliseerimine on üldiselt hea mõte. Peaksite proovima järgida normaliseerumise põhimõtteid, kui tundub mõistlik seda teha. Kuid kui kõik näitajad osutavad sellele, et normaliseerimine on liiga keeruline rakendada, kaaluge lähenemisviisi, mis aitab tööd teha, säilitades samal ajal teie andmed.
Lõpuks - kui te otsustate normaalsuse reeglitest kõrvale kalduda, olge eriti tähelepanelik andmebaasi terviklikkuse jõustamise kohta. Kui salvestate üleliigset teavet, asetage käivitajad ja muud kontrollid, et tagada, et teave jääb püsivaks.