[Conny Westh]

Det finns ett bra citat som jag själv tycker är suveränt enkelt för att komma ihåg var gränsen går för 3:e normalformen:

"The key, the whole key, and nothing but the key, so help me Codd."

Vad som menas är att det atomära värdet ska vara beroende av primärnyckeln, hela primärnyckeln, och ingenting annat än primärnyckeln. Då har man uppnått tredje normalformen och då slipper man redundans.

Edgar F. Codd (f. 1924, d. 2003) är ju matematikern som är pappa till relationsdatabasmodellen och relationsalgebran.

"so help med Codd" är ju en rolig grej i USA som är så religiösa av sig "so help me God" brukar de ju säga när de hoppas att allt ska gå bra.

Här är min källa för detta inlägg:
http://www.sqlmag.com/Article/ArticleID/38...rver_38896.html

[Conny Westh]

Originally posted by tozz@Jan 12 2009, 10:02
Normaliserade databaser har ju förmågan att bli otroligt långsamma, ifall det är webbapps vi pratar om.
Nu är jag inte emot normalisering (ifall någon trodde det), men efter att ha sett hur de som går "by the books" och normaliserar för normaliseringens skull slår huvudet i väggen när besökarna börjar trilla in så är det värt med en liten varning.

Som en kollega en gång sa "vi började med att lära oss databaser och byggde allting så normaliserat vi kunde, det var väldigt dumt"

Normalisering gör inte databasen långsam, det är när man inte indexerar och använder primärnycklar på ett korrekt sätt som det blir problem.

Jag har jobbat med gigantiska databaser hos banker, föräkringsbolag och myndigheter och tro mig eller ej men det är inte en korrekt utförd normalisering som ger långsamma databaser, det är frånvaro av eller slarvig optimering av index, frånvaro av primärnycklar och redundans som skapar problem.

Undantaget är om man ska göra massiva INSERT-satser som vid loggning av webbbesökare på Google, då kan det vara lämpligt att ha en enkel loggningstabell där alla INSERTsatser görs och att man vid några tillfällen per dygn hämtar in datat och bearbetar det i en annan databas för statistikbearbetning. Då är det lämpligt att inte använda indexering eller primärnycklar eftersom man är inte beroende på datakvaliteten utan man vill verkligen ha in all data rakt upp och ner utan kontroller.

Jag har sett skräckexempel där man får tablescan (att databasen måste läsa upp varenda post (egentligen i genomsnitt hälften) i hela tabellen för att hitta rätt värde i stället för att gå via ett index och hitta rätt värde med minimalt antal diskaccesser) stup i kvarten för att man ställer komplexa och dynamiska SQL-frågor utan att ha indexerat kolumner man använder i WHERE-klausulen.

Har man komplexa dynamiska SQL-frågor så kan man försöka optimera delar av dem genom att exempelvis skapa vyer elelr stored procedures för i båda dem fallen så förkompileras och optimeras anropet i den interna exekveringen hos databasen.

En del jobbar med optimering genom att använda table-cursors men det tycker jag är att gå för långt i de flesta fall, då ska det verkligen vara något sjuhelsikes prestandaproblem om man ska ge sig in på den typen av optimering. Det kostar alldeles för mycket i form av utvecklingstid och blir enormt kostsamt vid uppdateringar.

[tozz]

Om vi ska fortsätta med citat

"Normalised data is for sissies" (från sliden "JOIN's are slow")
- Cal Henderson

Redundans behöver inte vara något dåligt, det är vanligt professortänk som inte funkar speciellt bra i alla applikationer.

Tillbaka till topic I guess ^^

[tozz]

Ursprungligen postat av ConnyWesth

Normalisering gör inte databasen långsam, det är när man inte indexerar och använder primärnycklar på ett korrekt sätt som det blir problem.

Jag har jobbat med gigantiska databaser hos banker, föräkringsbolag och myndigheter och tro mig eller ej men det är inte en korrekt utförd normalisering som ger långsamma databaser, det är frånvaro av eller slarvig optimering av index, frånvaro av primärnycklar och redundans som skapar problem.

Undantaget är om man ska göra massiva INSERT-satser som vid loggning av webbbesökare på Google, då kan det vara lämpligt att ha en enkel loggningstabell där alla INSERTsatser görs och att man vid några tillfällen per dygn hämtar in datat och bearbetar det i en annan databas för statistikbearbetning. Då är det lämpligt att inte använda indexering eller primärnycklar eftersom man är inte beroende på datakvaliteten utan man vill verkligen ha in all data rakt upp och ner utan kontroller.

Jag har sett skräckexempel där man får tablescan (att databasen måste läsa upp varenda post (egentligen i genomsnitt hälften) i hela tabellen för att hitta rätt värde i stället för att gå via ett index och hitta rätt värde med minimalt antal diskaccesser) stup i kvarten för att man ställer komplexa och dynamiska SQL-frågor utan att ha indexerat kolumner man använder i WHERE-klausulen.

Har man komplexa dynamiska SQL-frågor så kan man försöka optimera delar av dem genom att exempelvis skapa vyer elelr stored procedures för i båda dem fallen så förkompileras och optimeras anropet i den interna exekveringen hos databasen.

En del jobbar med optimering genom att använda table-cursors men det tycker jag är att gå för långt i de flesta fall, då ska det verkligen vara något sjuhelsikes prestandaproblem om man ska ge sig in på den typen av optimering. Det kostar alldeles för mycket i form av utvecklingstid och blir enormt kostsamt vid uppdateringar.

Jag tror du är helt för låst i den gamla världens tänk och applikationerna som tillhör densamma. Joins är långsamma i sin natur, det spelar ingen roll om du har perfekta index.
Jag tvivlar på att banker eller försäkringsbolag ens kommer nära den simultana mängd användare som större webbplatser gör.

Om du verkligen vill ha normaliserad data så kan du alltid ha en denormaliserad db som kör dina queries mot och således slippa allt för många joins (replikera denormaliserad data vid inserts/updates).