Tietokannan normalisointi on yksi sovelluskehityksen pyhistä lehmistä. Jokainen suorittamasi ohjelmointikurssi tai kirja, jonka olet lukenut, saarnaa luultavasti tietokantojen normalisoinnin tärkeyttä. On aika haastaa tämä totuus. Joskus on OK denormalisoida tietokanta!
Milloin pitäisi normalisoida?
Tietokannan normalisointi suojaa tietojesi eheyttä. Se on hyvä idea monissa tapauksissa, ja sinun pitäisi aloittaa tietokannan suunnittelu normalisointia ajatellen. Jos pystyt normalisoimaan tietokantasi, tee se! Tärkeintä on, että sinä pitäisi normalisoi tietokantasi, ellei sinulla ole hyvää syytä olla tekemättä. Normalisointi on yleensä hyvä suunnittelukäytäntö. Se vähentää ylimääräistä tietoa, optimoi suorituskyvyn ja vähentää mahdollisuutta kokea tietojen eheysongelmia, jotka johtuvat samojen tietojen tallentamisesta tietokannan eri kulmiin.
Hyviä syitä olla normalisoimatta
On kuitenkin hyviä syitä olla normalisoimatta tietokantaasi. Katsotaanpa muutamaa:
- Osallistuminen on kallista† Tietokannan normalisointi edellyttää usein useiden taulukoiden luomista. Itse asiassa voit helposti päätyä yksinkertaiseen kyselyyn, joka kattaa viisi tai kymmenen taulukkoa. Jos olet joskus kokeillut viiden pöydän liittymistä, tiedät sen toimivan periaatteessa, mutta käytännössä se on erittäin hidasta. Jos rakennat verkkosovellusta, joka perustuu useisiin liitoskyselyihin suurille taulukoille, saatat ajatella: «Jos tätä tietokantaa ei olisi normalisoitu!» Jos kuulet tämän ajatuksen päässäsi, on hyvä aika denormalisoida. Jos voit pakata kaikki kyselyn käyttämät tiedot yhteen taulukkoon vaarantamatta tietojen eheyttä, tee se! Ole kapinallinen ja denormalisoi tietokantasi. Älä katso taaksepäin!
- Normalisoitu suunnittelu on vaikeaa† Jos työskentelet monimutkaisen tietokantaskeeman kanssa, törmäät todennäköisesti pääsi taulukkoon normalisoinnin monimutkaisuuden vuoksi. Yksinkertaisena nyrkkisääntönä voidaan todeta, että jos vietät koko päivän pohdiskellessaan, kuinka pääset neljänteen normaalimuotoon, saatat mennä liian pitkälle normalisoinnissa. Astu taaksepäin ja kysy itseltäsi, kannattaako todella jatkaa.
- Nopea ja likainen tulee olla nopea ja likainen† Jos olet vain kehittämässä prototyyppiä, tee se, mikä toimii nopeasti. Todellinen. Se on okei. Nopea sovelluskehitys on joskus tärkeämpää kuin tyylikäs muotoilu. Älä unohda palata ja tarkastella suunnitteluasi huolellisesti, kun olet valmis siirtymään prototyyppivaiheen pidemmälle. Hinta, jonka maksat nopeasta ja likaisesta tietokantasuunnittelusta, on se, että saatat joutua heittämään sen pois ja aloittamaan alusta, kun on aika rakentaa tuotantoa varten.
- Jos käytät NoSQL-tietokantaa, perinteinen standardointi ei ole toivottavaa. Suunnittele sen sijaan tietokantasi käyttämällä BASE-mallia, joka on paljon anteeksiantavampi. Tämä on hyödyllistä tallennettaessa jäsentämätöntä dataa, kuten sähköposteja, kuvia tai videoita.
Muutama varoituksen sana
Tietokannan normalisointi on yleensä hyvä idea. Sinun tulee yrittää noudattaa normalisoinnin periaatteita aina, kun se tuntuu järkevältä. Mutta jos kaikki indikaattorit viittaavat siihen, että normalisointi on liian monimutkaista toteuttaa, harkitse lähestymistapaa, joka voi suorittaa työn ja samalla suojata tietosi. Lopuksi, jos päätät poiketa normalisoinnin säännöistä, ole erityisen tarkkana tietokannan eheyden varmistamisessa. Jos tallennat tarpeettomia tietoja, käytä laukaisuja ja muita tarkistuksia varmistaaksesi, että tiedot pysyvät johdonmukaisina.