Morten Abildgaard skrev:
> Databasen indeholder 1 tabel til at holde kunde-informationer,
> 1 til at holde vikar-informationer og 1 til at holde
> administrator-informationer. Udover dem har jeg lavet en tabel
> til at holde informationer om ordrene, men her har jeg et et
> problem. Jeg vil nemlig have at databasen også skal holde både
> mødetider, pauser, normaltimer og overtimer for hver dag og
> for hver konsulent.
Konsulenterne udgør en selvstændig entitet - de skal have deres
egen tabel.
> Jeg har derfor lavet en ordre-tabel til at holde informationer
> om hver enkelt ordre,
God ide.
> og dernæst en tabel der hedder timer2003,
Skal der så laves en ny tabel næste år? Hvorfor ikke blot en tabel
til timeregistreringen - så kan man skrive datoen ind.
> hvor hver konsulent har en kolonne, og datoerne udgør rækkerne.
Det er i mine øjne en rigtig skidt ide. Hver gang der ansættes
eller fyres en konsulent skal du ind og pille i tabeldesignet. Og
det giver - som du også har fundet ud af - en meget stor mængde
kolonner.
Lav en tabel til konsulenterne og lad primærnøglen herfra være
fremmednøgle i timetabellen. Så får hver konsulent en række for
hver dag (tomme dage - altså dage hvor en konsulent ikke arbejder -
behøver ikke at blive oprettet).
> Tiderne bliver så skrevet ind i et array:
> 800;1600;30;7,5;0;0;0", der udgør hhv. mødetid, gå-hjem-tid,
> pause i minutter, normaltimer, overtid- start, overtid-slut og
> overtimer.
Det array fortjener til gengæld at blive fordelt - et felt pr
oplysning.
> Alternativt ville jeg lave 7 kolonner for hver konsulent, men
> så er jeg jo pludseligt oppe på mindst 700 kolonner, og det er
> vist lidt i overkanten, eller?
Det vil være håbløst at holde styr på. Laver du i stedet en kolonne
til hver af de 7 oplysninger i arrayet, en kolonne til at
identificere konsulenten og en kolonne til at registrere dagen - så
har du blot 9 kolonner at holde styr på.
Det gør ikke noget at der kommer mange flere poster i tabellen -
hvis der er fornuftige indeks på kan en database håndtere millioner
af rækker.
Med dine data får du umiddelbart 100 (konsulenter) x 360 (dage) =
36000 rækker (forudsat at samtlige konsulenter arbejder 360 dage om
året - nok lidt i overkanten). Det er mange rækker, men ikke flere
end de sagtens kan håndteres af en fornuftigt opbygget database.
Udregningerne bør kunne forløbe langt hurtigere end din nuværende
løsning - og som en tillægsgevinst kan du nu let og elegant styre
konsulenterne (ansættelser, fyringer eller almindelige
adresseændringer skal kun registreres ét sted).
--
Jens Gyldenkærne Clausen
MF (medlem af FIDUSO -
www.fiduso.dk)
I ovenstående tekst benyttes nyt komma.