08. december 2003 - 23:45Der er
27 kommentarer og 1 løsning
Hvad retfærdiggør redundans?
Hej,
Nu sidder jeg så og hjemmefedter noget MySQL-ting og støder så i følgende "problem":
Forestil dig at have en tabel med en sko-gruppe i, hvor hver sko-type har en id, en beskrivelse, etc. (eksempler på rækker kunne være "støvler", "sandaler", etc.). Endvidere haves en tabel med sko-mærker der refererer til (mindst) een af rækkerne i sko-gruppe-tabellen. Ydermere haves en tabel med de enkelte sko der er "på lager" i en tabel -- hver af disse refererer til een række i sko-mærke-tabellen.
Således "hænger" en sko altså på et sko-mærke som igen "hænger på" en sko-gruppe...
Spørgsmålet er så: Hvis jeg ønsker at have en "Lagerstatus sidst ændret" funktion for hver af sko-grupperne og sko-mærkerne, bør jeg så _kun_ opbevare en dato for hvornår den enkelte sko har "ændret sig", eller bør det opbevares i både sko-mærke-tabellen og sko-gruppe-tabellen også?
Helt generelt, hvor bør man bruge redundant informaiton, og hvornår bør man holde fingrene tæt til kroppen og lave et par kringlede queries til at nappe informationen ud på anden, og mere snedig vis?
Mit råd: - start med fuld normalisering - test om performance er OK - hvis ja fint - hvis nej prøver du at ændre strukturen lidt så så SQL sætningerne bliver simplere - det fortsætter du med indtil performance er acceptabelt
arne_v: Hmmm, det virker bare lidt omsonst at skulle "forsøge sig frem"... der må være nogle data på sådan noget (helt generelt) og dermed noget direkte faktuel viden -- eller tager jeg fejl; kan man slet ikke generalisere det? (Afhænger det for meget af databasen, strukturen af queries'ne, antallet af rækker i tabellerne, etc.?)
1) Lav et design uden redundans 2) Overvej ud fra dine forspørgsler nøje hvilke felter der skal indexer på 3) Er der stadig dyre forespørgsler med "mange" joins, så kan du introducere redundans for at få dem hurtigere. Opdateringer bliver dyrere, og uden transaktioner potentielt usikre.
Men husk også at en database server cacher mange ting, og er ganske effektiv til at joine små ting på. Og *vent* med 3)-eren til du ser en ineffektiv forespørgsel. Du skal ikke pre-optimere på et usikkert grundlag.
Undlad for alt i verden at bruge triggers. Du ender med at fortryde, når du engang i fremtiden sidder med et system, som du lavede for nogle måneder tilbage og skal finde ud af, hvorfor et eller andet opfører sig anderledes end du regner med. Jeg kan love dig for at trigger komplicerer tingene rigtigt meget.
Redundans kan også bruges til at sikre dine data. Tænk f.eks. på et ordre system med et katalog over varer (typisk e-handel). Her vil der over tid blive lagt ordrer og kataloget vil løbende ændre sig med nye varer, opdateringer af prisen osv.. For at holde ordrerne konsistente, vil man ofte gemme pris på ordrens linier, beskrivelse, farve ... ting, som kan ændre sig fra det tidspunkt, hvor ordren bliver afgivet.
Her giver det mening at have oplysningerne gemt flere stedet, idet du over en periode er nødt til at sikre at dine ordreoplysninger er korrekte.
Helt enig, arne_v. Det er et spørgsmål om hvilken forretningsmodel man lægger for dagen. Skal man betale den pris på varen, der er når man tager den ned fra hylden, eller den pris den har når man går til kassen. Begge dele kan forsvares, og er en af de beslutninger man skal tage i analysen af problemet. Det er ikke redundans.
mufoxe: man kan vel også snildt undgå at skulle gemme prisen i hver bestilling, simpelthen ved ikke at slette de gamle priser, men bare at have "alle de gamle" og så vælge den nyeste -- så kan man jo også lave en omgang rar statistik på sine priser :-)
Btw. hvad er det for en bog jeg skal have fat i om database design?
Hvis du ikke gemme prisen i din bestilling - minimum den der betales ved kassen - eller gemmer en reference til prisen, så har du problemer, når du vil se en gammel ordre. Den skal selvfølgelig indeholde den konkrete pris, som varen er købt med. Før det bliver en ordre, og det kun er en indkøbsvogn, kan man diskutere om prisen skal være med eller ej.
erikjacobsen: det er klart, naturligvis skal der være en reference... (det tænkte jeg, og overvejede slet ikke ikke at kunne undvære en sådan :-))
arne_v: alt hvad lokalbiblioteket finder når jeg søger på "C. J. Date" er "Bogen om Stauning" :-) Universitetsbiblioteket har dog endog et par bøger med førnævnte forfatter: "An introduction to database systems", "Relational database writings, 1994-1997" og andre, også i forskellige udgaver (udgivelsesår). "An introduction to database systems" er hermed bestilt og bliver hentet d. 18. december -- lige klar til juleferien :-)
Og jeg må hellere advare dig: C.J.Date's opfattelse af hvad der er på introducerende niveau ligger lidt over de fleste andres.
Men bogen er god. Solid teoretisk gennemgang. Og den forudsætter ikke så meget om ens database kundskab. Men det akademiske niveau er vel på universitet 2.-3. år.
Uhm, begge er bestilt -- napper den ene som læsning og den anden som suplement hvis der er afsnit jeg ikke forstår i den ene, så er det da muligt jeg forstår det på måden det er forklaret på i den anden :-) ... men nu må jeg se hvor meget tid der bliver i juleferien... der er jo også eksaminer og noget der skal passes i januar.
arne_v: hmm, jeg læser matematik på 3. semester, så niveauet er vel ikke fuldstændigt skudt forbi -- håber jeg :-)
Jeg staver/skriver som en dør i dag; "uhæld"... uheld, bare så ingen er i tvivl om at det ikke handler om noget "anti-aftagende" (voksende) eller måske "anti-afsluttende" (begyndende) ;-)
mufoxo: er du ikke rar at kaste lidt points videre til arne_v?
... ellers opretter jeg selv et ny spørgsmål, men jeg venter lige lidt for at se om mufoxo reagerer.
God nat :-)
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
