database struktur

Et par hurtige loese kommentarer:

- lad vaere med at saette size paa INT og DOUBLE da den ikke bruges til noget
- dine VARCHAR(3) kunne nok laves som CHAR(3) da der ikke er nok variabelt over dem
- undgaa TEXT hvis det ikke er absolut noedvendigt
- DECIMAL(6,6) duer ikke til valuta kurs DECIMAL(12,6) maaske xxxxxx.xxxxxx
- brug DECIMAL fremfor DOUBLE til price og quantity
- en del tabeller mangler en aktiv kolonne som du kan saette til false naar du "sletter" en raekke for man sletter naturligvis ikke selve raekken

Skal dine VER kolonner bruges til optimistic long time locking ?

Hej arne_v

Mange tak for feedback. Ja tanken er at bruge ver kolonner til optimistic long time locking. (Mange tak for artiklen) Dog er de "bare" smidt på, men der vil muligvis være nogle af dem der ikke er nødvendige. ex. "relations tabeller" der ex. forbinder users og roles

vedr. kolonne til sletning, vil det sige at du ALDRIG vil slette en kolonne i databasen? hvad så ved update, her bør man vel også gemme den "gamle" række eller? (bingo, så har vi versions styring!) Alternativt kan man "update" rækkerne med mindre man aktivt beder om en ny revision?

Hvis man gør dette, kan man gemme forskellige versioner, og så trække den nyeste når der hentes data (bliver hurtigt en stor database?). Eller skal det gøres i en seperat "history" database?.

INT og DOUBLE fjerner jeg size på. Hvad er egentlig forskellen på INT og INTEGER?

DECIMAL(6,6) troede egentlig at det var DECIMAL(før_komma,efter_komma) -> Her lærte jeg lige noget.

Jeg vil normalt ikke slaette en raekke i databasen. Hvis man sletter en kunde vil man ikke kunne genskabe tallene fra en given rapport paa et senere tidsounkt. Saa jeg ville saette kunden som inaktiv. Samme med stort set alt andet.

At have alle versioner af alle data i databasen bliver nok for tungt. Man kan leve med at kundens adresse er hans nuvaerende adresse og ikke den paa tidspunktet for ordren.

INT og INTEGER er synonymer.

OK. At trække vare og kundeoplysninger fra de respektive tabeller, og ikke gemme dette separat sammen med de øvrige ordreinformationer vil naturligvis være noget nemmere!

Kræver naturligvis at INGEN data slettes fra databasen som du skriver.

Vil denne tilgangsvinkel være ok iht. regnskabsloven? en faktura kan jo "ændres" efterfølgende!

Dette kan måske løses ved at gemme en "orginal" pdf faktura.

Takker for hjælpen indtil nu. Du må meget gerne smide et svar. poster nok løbende opdateringer til databasen her. hvis jeg skulle have flere spørgsmål.

Jeg kender ikke regnskabslovens krav.

Det er naturligvis noget som du skal have undersoegt.

og et svar

Hej Arne

Lige et lille spørgsmål mere. Jeg har nogle kolonner (INTEGER) hvor jeg indsætter 0 for inaktiv og 1 for aktiv. Hvilken datatype skal bruges hvis jeg i stedet vil have "true" og "false" og er der ide i at gøre dette?

Typisk vil man bruge TINYINT.

BOOLEAN er synonym for TINYINT.

Et eksotisk alternativ er ENUM med 2 passende værdier.

Takker for hurtig respons

Leder ikke efter eksotiske løsninger, men overskuelige og "rigtige"

Takker igen.