24. august 2004 - 12:46Der er
5 kommentarer og 1 løsning
Db design - tabelprobl.
Hej. Jeg sidder vist og sover lidt, hvilket gør at jeg ikke lige kan overskue mit db-system design. Jeg skal have lavet noget "ordre-system-styring".
Jeg har en tabel som indeholder de generelle informationer om hver ordre (ordrenr, kunde, dato, osv.)
Til hver ordre hører der en række af specifikke informationer omkring ordren. Hvilket ser nogenlunde således ud:
MODUL | KULØR | TYPE | ANTAL/SÆT | PRIS1 | PRIS2 | -------------------------------------------------- 0100 | mørk | støb | 1 | 2,1 | 2,1 | 0100 | tyrk | spra | 2 | 2,1 | 4,2 | 0150 | lyst | købt | 4 | 1,0 | 4,0 | -------------------------------------------------- og således fortsætter rækken af informationer til den specfikke ordre. og i varierende antal, med op mod 20-30 linier.
dvs. sådan en "tabel af informationer" hører der faktisk til hver eneste ordre.
Mit problem er at jeg ikke lige kan se hvordan jeg skal opbevare disse informationer, således at jeg nemt kan selecte/inserte/osv på dem - selvfølgelig med reference til den specifikke oredre.
Jeg kan se 3 forskellige måder at løse dette på.
1. Oprette en tabel for hver ordre, som hænger sammen med ordre-tabellen. Men det er jo helt hen i vejret, da det ville blive til rigtig mange tabeller.
2. at lave én stor tabel for specifikationerne, hvor hver række så indeholder data'ene + referencen til den ordre, som de hører til. Problemet her vil være at tabellen bliver rimelig stor (20-30 linier pr. ordre * omkring 500-1000 ordrer om året) Oveni vil det give en masse redundans, da mange ordrer har de samme specifikationer. Men nok den absolut nemmeste løsning (også mht. select)
3. den tredje løsning jeg går og pusler med, er noget a'la: Ordre (har en) SpecSamling (har flere) Specs (jeg prøver vist at lave noget E/R-diagram-snak :) ) Det må blive noget med 3 tabeller eller deromkring. Jeg kan bare ikke lige overskue det. Min hjerne er vist kørt i fisk.
Er der nogen som lige kan give mig løsningen på mit problem :)
Ang. redundans, så mener jeg at det er en god praksis at du gemmer oplysninger som pris m.m. i "ordrelinietabellen". Disse ting vil jo kunne ændre sig (især prisen), og på denne måde bliver det registreret præcis hvilke vilkår kunden blev præsenteret for i købsøjeblikket.
ja ordre tabel + ordre linie tabel er meget kendt, men det som jeg er lidt ked af :) er at til hver post i ordre tabellen, skal der høre omkring 30 ordre linier til. Hvilket jeg synes er lidt underligt når man skal til at hente data'ene ud igen. Men det er muligvis korrekt som du (arneV) skriver at jeg skal lave primærnøgle og fremmednøgle.
Hvisa hver ordre består at 30 varer, jamen så skal der da være 30 poster, plus én i ordretabellen. Hvad er problemet? Det antal posterdu taler om er jo så lille at det sagtens kunne håndteres af en Access database, og vi taler om MS SQL her. 5-10 millioner poster ville ikke være et problem.
Den letteste måde at forklare indexer på, er at du med dem forbereder databasen på hvilke felter du vil bede den om at sortere eller vælge efter. Så når du kommer og siger "SELECT Felt1, Felt2 FROM OrdreLinie WHERE OrdreID = 2546", så kan den gøre det lynhurtigt, hvis du har lavet et index på kolonnen OrdreID.
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.
