repsac Nybegynder
08. december 2003 - 23:45 Der 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?


På forhånd tak!
arne_v Ekspert
08. december 2003 - 23:50 #1
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
repsac Nybegynder
08. december 2003 - 23:53 #2
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.?)

Jeg tager skam dit råd til mig, men... :-)
erikjacobsen Professor
08. december 2003 - 23:54 #3
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.
repsac Nybegynder
09. december 2003 - 00:03 #4
erikjacobsen:
Det lyder som vældigt kloge ord.
Btw. "transaktioner", er det det der på PgSQL'sk hedder "triggers"?
arne_v Ekspert
09. december 2003 - 07:47 #5
Pointen er at du ikke skal gøre dit database design dårligere førend du
ved at det er absolut nødvendigt.

Og det er svært at sige noget generelt om det, fordi det afhænger af dine
SQL sætninger og dine performance krav.
arne_v Ekspert
09. december 2003 - 07:48 #6
transaktioner = begin/commit/rollback = "bundtning" af flere SQL sætninger

triggers = SQL der køres ved INSERT/UPDATE/DELETE i tabel
trer Nybegynder
09. december 2003 - 09:00 #7
arne_v; MySQL har ikke triggers og procedurer - men har vistnok fået transaktioner nu...

repsac: prøv at søge efter "normalisering" og "normalform" sammen med "sql" og "database" på google. Typisk 2-3 normalform for et kørende system.
arne_v Ekspert
09. december 2003 - 09:04 #8
MySQL har haft transaktioner i lang tid (med InnoDB tabeller).

Triggers og stored procedures er planlagt til V5.
trer Nybegynder
09. december 2003 - 09:30 #9
Jep. Ville blot præcisere da du nævnte transaktioner og triggers i den her kategori (har ikke rigtigt kigget på MySQL i nogle år).
mufoxe Nybegynder
09. december 2003 - 10:07 #10
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.
mufoxe Nybegynder
09. december 2003 - 10:10 #11
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.
arne_v Ekspert
09. december 2003 - 10:17 #12
Teknisk set er der ikke redundante data i det eksempel !

current pris og pris på salgs tidspunkt er ikke det samme
erikjacobsen Professor
09. december 2003 - 10:19 #13
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.
repsac Nybegynder
10. december 2003 - 22:54 #14
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?
arne_v Ekspert
10. december 2003 - 23:04 #15
For database teorien: C.J.Date

Men for den mere praktik anvendelses orienterede kender jeg ikke nogen
gode.
erikjacobsen Professor
10. december 2003 - 23:10 #16
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.
repsac Nybegynder
10. december 2003 - 23:21 #17
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 :-)
repsac Nybegynder
10. december 2003 - 23:22 #18
"ikke ikke" -- jeg kan vist nøjes med et enkelt "ikke" :-)
arne_v Ekspert
10. december 2003 - 23:25 #19
Det er "Introduction ..."

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.
erikjacobsen Professor
10. december 2003 - 23:26 #20
arne_v Ekspert
10. december 2003 - 23:34 #21
Sikkert også en glimrende bog.

Formentlig også mere uptodate.

Men ikke så klassisk.
repsac Nybegynder
10. december 2003 - 23:40 #22
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 :-)
repsac Nybegynder
10. december 2003 - 23:48 #23
Hey, hov!

Jeg fik ved et uhæld (tilsyneladende) accepteret mufoxo's svar... ?

mufoxo: er du villig til at give points videre til dem jeg nu enerådigt beslutter skal have dem?
repsac Nybegynder
10. december 2003 - 23:50 #24
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) ;-)
erikjacobsen Professor
10. december 2003 - 23:53 #25
Ingen point til mig, tak
repsac Nybegynder
11. december 2003 - 00:04 #26
erikjacobsen: ok.

arne_v: vil du modtage en lille sjat point?


I øvrigt, tusind tak for jeres hjælp!
arne_v Ekspert
11. december 2003 - 00:14 #27
Jo tak - jeg siger sjældent nej til point.
repsac Nybegynder
11. december 2003 - 00:16 #28
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 :-)
Ny bruger Nybegynder

Din løsning...

Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links

Opret Preview

Log ind eller opret profil

Hov!

For at kunne deltage på Computerworld Eksperten skal du være logget ind.

Det er heldigvis nemt at oprette en bruger: Det tager to minutter og du kan vælge at bruge enten e-mail, Facebook eller Google som login.

Du kan også logge ind via nedenstående tjenester





Computerworld
Det nye MitID er et tigerspring for bedre cybersikkerhed
Klumme: Det nye MitID er en enestående mulighed for et markant løft af it-sikkerheden i danske kommuner. Med baggrund i udfasningen af det nuværende NemID kan de samtidig forbedre og styrke deres it-systemers værn overfor cyberangreb.
CIO
Podcast: Hos Viking Life-Saving Equipment er it gået fra at være backend til at være noget, som kunderne spørger aktivt efter
Podcast, The Digital Edge: Viking leverer en stadig større del af deres produkt som en tjeneste. Som en del af tjenesten tager Viking ansvar for sikkerheden ved at levere, dokumentere og vedligeholde det nødvendige sikkerhedsudstyr. Hør hvordan Henrik Balslev senior digital director hos Viking har løftet den opgave.
Job & Karriere
Regner din ferie væk? Brug tiden på at søge en af disse otte stillinger, der er ledige netop nu
Det sjasker ned over hele Danmark. Du kan bruge de våde sommerdage på at søge et af disse otte job, der er ledige lige nu.
White paper
Sådan kan du arbejde effektivt uanset tid, sted og type af enhed
Hvad nu hvis dit arbejde, din information, dine processer og teknologien bag ved, var organiseret på en måde så det passede til din organisation – alt sammen guidet af en intelligent udgave af det digitale arbejdsrum? Det er visionen bag Atea og Citrix´s samarbejde med digital workspace – en smartere og mere effektiv måde at arbejde på. I dette whitetpaper kan du derfor læse om, hvordan du kan skabe et mere effektivt og brugervenligt arbejdsrum uanset tid, sted og enhed. En løsning der på en gang er både enkel og som sætter brugeren i centrum.