Er denne struktur fin ?

Du mangler en tabel med varelinier, OrdreVareLinie plejer jeg at kalde den. Den skal have et felt der hedder OrdreID der skal relatere til ID i Ordre.

I den tabel vil du registrere ProduktID og Pris, så hvis prisen ændres i Produkter, vil gamle ordrer stadig findes med gammel pris.

Måske har du allerede gjort det, men jeg opfatter det som om at Tabellen Produkter er din Vareliste. Hvis du bruger Produkter som OrdreVareLinie, så må det betyde at feltet VareNumre bruges til at relatere til Ordre. Det er forkert, du skal have et OrdreID i Produkter i stedet.

Og så vil jeg foreslå at du Bruger ID i tabellerne som nøgle i stedet for at lave et andet felt ti det formål. Eks:

Tabellen Kunder (Som egentlig kunne hedde Kunde) har et felt der hedder Id. Jeg går udfra at det er Primær nøgle. Og så har du et der hedder KundeID. Omdøb i stedet Id til at hedde KundeID, og drop det nuværende KundeID.

den umiddelbare fordel er at Primærnøgler altid er indexerede, hvilket har afgørende betydning for performance. Og hvis Id er Autoincrement, så behøver du ikke at bekymre dig om dublerende KundeID

Har sat det nye op sådan her: http://www.thedeathart.dk/upload/dbStruktur_2.jpg

Men er lidt i tvivl om hvordan OdreVareLinje skal forståes, så hvis du kan uddybe den lidt.

Jeg går udfra at man skal kunne bestille flere varer i samme ordre.

En ordre består så af: En post i Kunde. En post i Ordre, med KundeID = KundeID fra Kunde-tabellen. Et antal poster i OrdrevareLinie, hver med OrdreID = OrdreID fra OrdreTabellen.

OrdreVarelinie skal bl.a. have felterne:
OrdreVarelinieID
OrdreID
VareID
Varetekst
Pris
Antal

Jeg går udfra at du har et varesortiment, lad os sige at den findes i tabellen Vare, og hver vare har et VareID, en VareTekst, en Pris, og en masse andet. Idet ordren oprettes vil jeg vælge at overføre Varetekst og Pris fra tabellen Vare til tabellen OrdreVarelinie, for så kan man altid bagefter se hvad varen kostede og hvad dens varetekst var da ordren blev oprettet.

I OrdreVarelinie vil du desuden gemme VareID, om ikke andet så for at kunne lave en oversigt over hvem der har købt hvor meget af en bestemt vare.

Ja , dine antagelser er korrekt :)

Jeg havde selv forestillet mig at have alle ordre i ordre tabellen, men kan godt se at endnu en tabel gør det smartere.

Så http://www.thedeathart.dk/upload/dbStruktur_3.jpg burde være mere optimalt, hvis jeg vel og mærke har fået det hele med ?

Ja, det ser godt ud

Men jeg er stadig forvirret over Produkter! Er det dit varekartotek? Og hvis ja, hvorfor er der så en kolonne der hedder antal? Er det hvis der er 12 stk i en æske, eller hvad?

De to kolonner Pris og VareTekst i OrdreVarelinie skal altså udfyldes med de tilsvarende fra Produkter idet ordren oprettes, så skulle du ikke kalde kolonnerne det samme i Produkter?

I Ordre/OrdreVarelinie:
Kan du ikke ligesågodt kalde det OrdreID, ligesom du kalder det KundeID?

I Produkter:
Hvis det er det varekartotek, så ville jeg kalde den Produkt, med nøglen ProduktID, eller Vare, med nøglen VareID. Her har du stadig "to nøgler", som jeg nævnte tidligere.

I OrdreVarelinie skal kolonnen hedde det samme, enten VareID eller ProduktID.

Nu begynder det rigtig at ligne noget. Det er en rigtig god ide at gennemtænke dette grundigt fra start, for det er noget rigtig rod hvis der skal ændres for meget når man først er i gang med projektet for alvor.

Meget af det jeg siger er det man kalder konventioner, bestemte måder at navngive tingene på, som de fleste programmører kan tilslutte sig. Du har selvfølgelig lov at kalde tabellerne hvad du vil, det vil ikke have betydning for hvordan databasen virker. Men det er meget vigtigt at du definerer primærnøgler i alle tabeller, og at det er dem du bruger til at joine tabellerne sammen med senere.

Jeg følger disse konventioner (blandt andre):
Tabeller navngives i ental, dvs at det hedder Kunde, ikke Kunder, og Ordre, ikke Ordrer.
Primærnøglen hedder <Tabelnavn>ID, dvs. KundeID og OrdreID. De felter i andre tabeller som de skal joines med hedder det samme.

Alle felter som ikke er nøgler gives et prefiks der angiver datatypen. Fx., vil jeg kalde VareTekst for strVareTekst, og Antal for intAntal. Jeg benytter følgende prefiks:
str - varchar, char
int - integer
dtm - dato og klokkeslet
txt - Langt tekstformat, det kan hedde notat eller text
b - bit, typisk brugt som Ja/Nej-felt

ja , Produkter skal være mit varekartotek, antal er antal af produkter på lager.
Havde aldrig hørt om konventioner inden for SQL :)
Vil lige prøve at lave en forbedre udgave igen :)

Tak

http://www.thedeathart.dk/upload/dbStruktur_4.jpg

Har omdøbt Produkter til VareKartotek, og tilpasset hist og her.

OK, det ser godt ud. Men jeg vil foreslå at du dropper "Kartotek" delen af navnet.

Kunde hedder heller ikke Kundeliste eller Kundekartotek eller Kunder, for man giver tabellen navn efter hvad en post på listen er for en størrelse; en Vare, en Kunde. At det er en liste, det ved vi godt, for det er jo hele ideen med en tabel.

I øvrigt har du skrevet Kartokek i stedet for Kartotek nogle steder. Check godt efter, for en stavefel i et kolonnenavn må man leve med i mange år, og man bliver SÅ træt af det. Jeg var med til at lave en database, hvor min medprogrammør mente at Abonnement staves Abonement, og det var rigtig svært at huske hvornår man skulle og ikke skulle bruge dobbelt n.

De streger du har tegnet et det relationer, dvs. key/foreign key? For så skal du slette dem mellem txtVareTekst og dblPris i OrdreVarelinie og Vare. Meningen er jo netop at prisen GODT må ændres senere, hvilket en fast relation ville forhindre. I øvrigt var det faktisk strVareNavn jeg ville have overført, ikke txtVareTekst, men det må du selv bestemme, blot er du nødt til at gøre det med prisen, for den vil jo helt sikkert ændre sig.

Et par ting mere:

Kald det intLager i stedet for intAntal

Du bruger dbl, hvilket jeg antager er et decimal format, til prisen, overvej at bruge integer, og lad alle beløb være i ører. Jeg synes selv at decimaltal er besværlige at have med at gøre, så jeg laver altid alle beløb i ører, og så skal jeg blot dividere dem med 100 når de skal præsenteres for brugeren. Men hvis du er vant til dbl, så er det helt fint.

Nu tror jeg også jeg har ævlet nok, blot et sidste forslag:

Du har en strStatus på Ordre, og der vil du nok skrive "Oprettet", "Afsendt", "Annulleret" osv. ikke? Lav i stedet to tabeller:

OrdreStatusKode:
OrdreStatusKodeID int PK
strStatusTekst

I den står der fx.
0  Oprettet
20 Afsendt
50 Afsluttet
-10 Annulleret

Det er altså en liste over statusser en ordre kan få.


og:

OrdreStatus:
OrdreStatusID int, autoincr. PK
OrdreID int
dtmDato datetime
OrdreStatusKodeID int


I den skriver du en linie hver gang der sker noget med en ordre. Så hvis ordre nr 4567 bliver annulleret 25/7 2005, så skriver du en linie sådan

<autonr>, 4567, 25/7 2005, -10

På den måde for du en historik over hver ordre, så du bagefter kan se præcis hvornår den er oprettet, afsendt osv.

Men god arbejdslyst med det!  :o)
Hilsen Lars D

:D

Så er der vist at være styr over det, så vil jeg sige rigtig mange mange tak for hjælpen.
Og lige bede om et svar for de velfortjente points :)

Et lille bonus spm.

Ville det være OK at smide admin-brugererne ind i Kunde tabellen, eller bør jeg have en externe til det.

I så fald skal der vel et LevelID og en tabel med LevelID og strNavn i, korrekt ?-)

Du vil registrere en række personer der har adgang. Når én forsøger at få adgang skal der slås op i en tabel for at se om det er ok.

Hvis almindelige Kunder også skal kunne logge ind kan du samle det i kundetabellen, og ja, som du siger en tabel med Levels vil være fint