[tartareandesire]

Originally posted by ConnyWesth@Jun 27 2009, 01:49
Min misstanke är att trådskaparen vill kunna visa de 10 senast registrerade medlemmarna på webbsidan, och då skulle min enkla SELECT vara exakt det som är det han vill åstadkomma.
Att över huvud aget ha en extra kolumn med data med i detta fall reduntant information som enkelt kan fås genom en simpel SELECT är inte helt optimalt.

Det kan i vissa speciella fall faktiskt vara en bra idé att ha redundant information. Nu är med största säkerhet inte detta ett sådant fall dock även om det är svårt att veta exakt vad trådskaparen vill åstadkomma. Om han vill förklara det så är det lättare för alla att ge relevanta svar. Även om själva sql-satsen är trivial så finns det kanske en bättre lösning på problemet bakom.

[Conny Westh]

Originally posted by tartareandesire@Jun 27 2009, 14:18
Det kan i vissa speciella fall faktiskt vara en bra idé att ha redundant information.

Ge mig ett exempel som är bra!

[Clarence]

Ursprungligen postat av ConnyWesth

Ge mig ett exempel som är bra!

Det finns enormt många exempel. Det allra mest förekommande för de flesta webbapplikationer är nog ett färdigbearbetat träd eller lista med t ex kategoristruktur, tillhörande personer eller relaterade taggar där alternativet skulle vara krävande joins och/eller rekursiva funktioner. Det engelska begreppet för detta brukar vara "denormalization" och görs normalt sett av prestandaskäl (och bör användas tillsammans med normalisering, inte som alternativ).

[Conny Westh]

Originally posted by Clarence@Jun 27 2009, 21:59
Det finns enormt många exempel. Det allra mest förekommande för de flesta webbapplikationer är nog ett färdigbearbetat träd eller lista med t ex kategoristruktur, tillhörande personer eller relaterade taggar där alternativet skulle vara krävande joins och/eller rekursiva funktioner. Det engelska begreppet för detta brukar vara "denormalization" och görs normalt sett av prestandaskäl (och bör användas tillsammans med normalisering, inte som alternativ).

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

[Clarence]

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å.