Visa ett inlägg
Oläst 2009-06-28, 00:04 #5
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Clarence Clarence är inte uppkopplad
Administratör
 
Reg.datum: Jan 2003
Inlägg: 1 974
Citat:
Originally posted by ConnyWesth@Jun 27 2009, 22:21
Hmmm, det exemplet är ju ett typiskt exempel när normalisering är ett måste för att det ska fungera över huvud taget....

De exempel jag känner till som dubbellagring kan förekomma är just vid omvanling (eller "tvätt") av ostrukturerat data så den blir mer normaliserad i slutändan. Då brukar man jobba i flera steg med mellanlagring av informationen.

Sen finns det exempel med DataWarehousing där man har extrema mängder transaktionsinfo på *låg nivå som ska samamnställas till statistik i beslutsstödsammanhang.

Jag har jobbat med replikering av data till mobila arbetsstationer, och där kan finnas en anledning till dubbellagring av information.

Men jag tänker nu på dubbellagring i samma databas "on site" så att säga. Det brukar vara särdeles olämpligt att dubbellagra information ur kvalitetssynpunkt eftersom man får svårt att avgöra vilken information som är korrekt när något intse stämmer.

Redundans = En dålig grej ur kvalitetssynpunkt!

Men det exempel du tog upp får du nog förklara mer ingående innan jag tror dig....
Data warehousing är enligt mig snarare ett exempel där långtgående normalisering ofta inte är önskvärt från första början (se t ex Star Schema eller Snowflake design).

Begreppet avnormalisering (mitt försök till översättning av "denormalization", rätta mig gärna) som jag främst syftade på blir dock mindre tillämpligt där då det oftast används där datan redan finns i normaliserad form (notera också att "denormalization" inte beskriver huruvida datan finns kvar i sin normaliserade form, oftast finns den dock det).

Den grundläggande anledningen till att avnormalisering är önskvärt just för att det krävs mindre av läsningar för att hämta all relevant data till ... låt oss säga en forumtråd. I de allra flesta forumprogramvaror lagras t ex medlemmens (smek)namn i samma tabell som inläggen. På så vis slipper man en join mot användartabellen där varje användarid som varit aktiv i tråden måste hämtas. Kostnaden för SELECTS vid visning av inlägg blir därmed mindre, men kostnaden för en uppdatering av användarnamnet blir mycket större - eftersom den måste uppdatera samtliga raderna av medlemmen i inläggstabellen. Själva principen bygger på att man vet med sig att användarnamn kommer läsas väldigt mycket oftare än ändras.

I andra fall kan det vara att t ex bearbeta en summa som sen sparas - t ex antalet poster i forumet "Serversidans teknologier". Att behöva räkna dessa varje gång forumets förstasida laddas är onödigt - då det uppdateras några gånger i timmen eller så.

Ur kvalité-synpunkt är det väl närmare negativt än positivt, men så länge man vet att redundansen finns och eventuellt använder en transaktionssäker databas om det behövs bör det inte vara ett problem.

Cache-system eller inbyggda cache/index-funktioner i ett RDBMS kan ibland ersätta hela eller delar av behovet av avnormalisering, men ofta är de snarare overkill och blir ett extra system att hålla koll på.
Clarence är inte uppkopplad   Svara med citatSvara med citat