Normalizavimas realiame pasaulyje
Duomenų bazių normalizavimas yra viena iš šventų programų kūrimo karvių. Kiekvienas bakalauro programavimo kursas, kurį jūs skaitėte arba kurį skaitote, galbūt pasakoja apie duomenų bazių normalizavimo svarbą.
Atėjo laikas ginčyti šį tiesa. Kartais tai gerai, jei norite denormalizuoti savo duomenų bazę!
Kada reikia normalizuoti?
Duomenų bazės normalizavimas apsaugo jūsų duomenų vientisumą. Tai puiki idėja daugeliu atvejų, ir jūs turėtumėte pradėti bet kokią duomenų bazių projektavimo veiklą, atsižvelgdami į normalizavimą. Jei galite normalizuoti savo duomenų bazę, eik į ją! Tiesą sakant, čia yra keletas praktinių patarimų, kaip normalizuoti savo duomenų bazę šioje svetainėje:
- Duomenų bazės įvedimas į pirmąją įprastinę formą (1NF)
- Antrosios įprastos formos duomenų bazės įkėlimas (2NF)
- Duomenų bazės įvedimas trečioje įprastoje formoje (2NF)
Bottom line yra tai, kad turėtumėte normalizuoti savo duomenų bazę, nebent turite tikrai svarbios priežasties to nedaryti. Paprastai normalizavimas yra garso dizaino praktika. Tai sumažina nereikalingą informaciją, optimizuoja našumą ir sumažina tikimybę, kad turėsite duomenų vientisumo problemų, kurios atsiranda dėl to, kad tie patys duomenys buvo užblokuoti skirtinguose jūsų duomenų bazės kampuose.
Keletas gerų priežasčių normalizuoti
Tuo tarpu yra keletas svarbių priežasčių, kodėl jūsų duomenų bazė normalizuojama. Pažvelkime į keletą:
- Prisijungimas yra brangus . Normalizuojant savo duomenų bazę dažnai reikia sukurti daugybę lentelių. Iš tikrųjų galite lengvai užbaigti tai, ką manote, turėtų būti paprastas užklausas, apimantis penkis ar dešimt lentelių. Jei kada nors bandėte prisijungti prie penkių stulpelių, žinote, kad jis veikia iš esmės, tačiau praktiškai jis lėtas. Jei kuriate žiniatinklio programą, kuri remiasi daugkartinio prisijungimo uždaviniais prieš didelius lenteles, galite pajusti mąstymą: "Jei tik ši duomenų bazė nebūtų normalizuota!" Kai girdi tą minties galvą, tai tinkamas laikas apsvarstykite denormalizavimą. Jei galite laikyti visus duomenis, kurie buvo naudojami ta užklausa, į vieną lentelę, nekeliant pavojaus jūsų duomenų vientisumui, eik tai! Būk maištininkas ir denormalizuokite savo duomenų bazę. Jūs neatsiversite atgal!
- Normalizuotas dizainas yra sunkus . Jei dirbate su sudėtinga duomenų bazės schema , tikriausiai pamatysite, kaip stengėsi nukreipti galvą prieš lentelę dėl normalizavimo sudėtingumo. Paprastai nykščio taisyklei, jei praleidžiate visą dieną, bandydami išsiaiškinti, kaip pereiti į ketvirtąją normalią formą, pernelyg didelė normalizacija. Grįžkite ir paklauskite savęs, ar tai tikrai verta tęsti.
- Greitas ir purvinas turėtų būti greitas ir purvinas . Jei planuojate kurti prototipą, tiesiog atlikite tai, kas greitai veikia. Tikrai. Viskas gerai. Greitas programų kūrimas kartais yra svarbesnis už elegantišką dizainą. Tiesiog nepamirškite grįžti ir atidžiai pažvelgti į savo dizainą, kai būsite pasirengę pereiti pro prototipus. Kaina, kurią mokate už greitą ir nešvarią duomenų bazių projektą, yra tai, kad jums gali prireikti jį išmesti ir prasidėti, kai laikas pagaminti gamybai.
- Jei naudojate NoSQL duomenų bazę , tradicinė normalizacija nėra pageidautina. Vietoj to suprojektuokite savo duomenų bazę naudodami BASE modelį, kuris yra daug maloniau. Tai naudinga, kai saugote nestruktūruotus duomenis, pvz., El. Laiškus, vaizdus ar vaizdo įrašus.
Kai kurie atsargumo žodžiai
Paprastai duomenų bazės normalizavimas yra gera idėja. Turėtumėte pabandyti laikytis normavimo principų, kai atrodo pagrįsta tai padaryti. Tačiau jei visi rodikliai rodo, kad normalizavimas yra pernelyg sudėtingas, apsvarstykite požiūrį, kuris atliks darbą, tuo pačiu apsaugant jūsų duomenis.
Galiausiai - jei jūs nuspręsite nukrypti nuo normavimo taisyklių, būkite ypač budrios dėl to, kaip vykdote duomenų bazės vientisumą. Jei saugote nereikalingą informaciją, įdiekite aktyviklius ir kitus valdiklius, kad įsitikintumėte, jog informacija išlieka nuosekli.