Normaliserings regler/former (database)

du har jo selv svaret ;o)

hvis man er "normaliseringsfreak" så har du f.eks. postnummer og by i sin egen tabel og referer til den/byen/postnummer via "ID" (tabel id). Jeg "smider" for det meste bare postnummer og by ned i f.eks. bruger tabellen (data kommer dog som regel fra en "postnummer" tabel, som "ryger" direkte i databasen). Det er ikke normaliseret, men det er en del hurtigere at hente ;o)

Du skal ikke gå for meget op i det, det er min mening...

Lav din database så DU kan finde ud af den, men du må godt "tænke" lidt du skal ikke f.eks. skrive brugernavn (til f.eks. et svar her på exp) i databasen, men brugerens ID)

;o)

Alt afhængig af din databases kompleksitet og størrelse kan der være fra negativ performance-ændring til ganske betydelig performance forbedringer ved at normalisere mere eller mindre ...

Har du en liste, hvor din allernærmeste familie står, vil det være vildt overkill at lave en postnummer-tabel, en job-tabel m.m.m. (det kan faktisk ofte betale sig bare at sætte det ind i et Excel-ark eller en Office (adresse-)liste !-), men har du en database over 30.000 brugere af et-eller-andet, som du skal slå op i på alle mulige måder, kan du opnå betydelige fordele ved at normalisere ...

Prøv at google: http://www.google.dk/search?hl=da&q=normalisering&meta= -- andet link i min søgning: http://www.hager.dk/noter/m0enot01.html !o]

roenving -> flot eksempel, beskriver det perfekt (normaliseringsformerne) ;o)

MEN, kan du ikke give mig ret i at det er hurtigere at søge i en database (efter f.eks. bynavn), hvor det (bynavn) ligger sammen med/i "bruger" tabellen?

Nu er bynavne og postnumre ikke noget der ændrer sig særlig tit, så der "skal" man ikke normalisere, andre "ting" skal man... produkter f.eks. (hvis du ændrer pris skal det kunne ses "alle steder" med det samme), så er det ikke smart at have en anden tabel med navn, pris osv...

hvis du går helt N3 "amok" så skal alle navne, gader, biler osv også være "normaliseret" ;o)

Det er korrekt, netop derfor lægger jeg også ud med at problematisere behovet for normalisering ...

-- og præcis opslag/søgning har jeg jo også fat i, relationelle professionelle databaser vil oftest performe betydeligt bedre ved fuld normalisering, men skal du finde de familiemedlemmer, der kører i Wartburg, vil søgningen nok være hurtigere i et Excel-ark, hvor bil-mærket er en kolonne ...

-- skal du derimod søge det i en meget omfattende database, vil det være betydeligt mere effektivt at finde nøgle-id på den record, der indeholder bilmærket og så finde de stamrecords, der indeholder den fremmednøgle !-)

Skal man skyde med kanoner, er det uhensigtsmæssigt at forsøge at ramme gråspurve !o]

-- skal du derimod søge det i en meget omfattende database, vil det være betydeligt mere effektivt at finde nøgle-id på den record, der indeholder bilmærket og så finde de stamrecords, der indeholder den fremmednøgle !-)

Ja, det kan det være hvis dine indexer er på plads (går udfra at du mener søger efter f.eks. bmw i "bilmærke tabellen", derefter "matcher" db'en med "anden" record ) ;o)

Jepz, nøgle-indexer er betydeligt mere effektive, og sådan som jeg har forstået det, vil de også fylde adskilligt mindre og på den måde gavne effektiviteten i de 'professionelle' databaser ...

ja da "integere"(tal) "fylder" jo ikke så meget som bogstaver og er "nemme" at håndtere, f.eks. "giv mig firmaet med id nr 1", eller "giv mig firmaet der hedder toms"...

lidt normalisering er "ok", og effektivt (nødvendigt)... Men der er undtagelser....

En stor ikke-normaliseret database bliver da også et mareridt at vedligeholde/holde opdateret. I stedet for at ændre en given værdi eet sted, skal man måske ændre den rigtig mange steder. Hvis man glemmer et af stederne, vil dataintegriteten være ødelagt. Så 3 NF må da være at foretrække.

I en stor database, ja ...

I den lille over familiemedlemmerne, vil det være mere logisk at ændre navnene på tante og onkel og fætre og kusiner i familien, hvis den familie ændrer efternavn !-)

Hvis det er adresserne til dem man skal sende julekort, så er alt jo godt nok.

Men skal man lave en seriøs database, så skal man altid starte med at normalisere
til mindst 3NF/BCNF. Så performance tester man.

Og hvis:
  * man har et alvorligt performance problem
  * tilføjelse af index ikke kan løse problemet
  * ens database understøtter ikke materialized views
så kan man begynde at eksperiementere med denormalisering.

Noget helt andet, som taler til fordel for en normaliseret database er, at det er måske ikke dig selv, der skal vedligeholde den ......

Så udover normalisering er det vigtigt med en konsekvent og gennemtænk navnekonvention ;-)

Uha, godt at se man kunne sætte en lille konstruktiv debat igang omkring emnet :) Men rigtig gode svar, har helt sikkert gjort mig klogere..

roenving og a1 smid lidt et svar begge, så smider jeg nogle points i nakken på jer :)

Velbekomme '-)