Citat:
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.