Avatar billede 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!
Avatar billede 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
Avatar billede 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... :-)
Avatar billede erikjacobsen Ekspert
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.
Avatar billede 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"?
Avatar billede 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.
Avatar billede 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
Avatar billede 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.
Avatar billede 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.
Avatar billede 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).
Avatar billede 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.
Avatar billede 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.
Avatar billede 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
Avatar billede erikjacobsen Ekspert
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.
Avatar billede 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?
Avatar billede 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.
Avatar billede erikjacobsen Ekspert
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.
Avatar billede 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 :-)
Avatar billede repsac Nybegynder
10. december 2003 - 23:22 #18
"ikke ikke" -- jeg kan vist nøjes med et enkelt "ikke" :-)
Avatar billede 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.
Avatar billede erikjacobsen Ekspert
10. december 2003 - 23:26 #20
Avatar billede arne_v Ekspert
10. december 2003 - 23:34 #21
Sikkert også en glimrende bog.

Formentlig også mere uptodate.

Men ikke så klassisk.
Avatar billede 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 :-)
Avatar billede 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?
Avatar billede 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) ;-)
Avatar billede erikjacobsen Ekspert
10. december 2003 - 23:53 #25
Ingen point til mig, tak
Avatar billede 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!
Avatar billede arne_v Ekspert
11. december 2003 - 00:14 #27
Jo tak - jeg siger sjældent nej til point.
Avatar billede 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 :-)
Avatar billede 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. Der sættes "nofollow" på alle links.

Loading billede Opret Preview
Kategori
Computerworld tilbyder specialiserede kurser i database-management

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