/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Database-layout til tidsregistrering
Fra : Morten Abildgaard


Dato : 03-02-03 22:28

Hej flinke mennesker,

Jeg er ved at lave en database til en online tidsregistrering for et
vikarbureau, og kunne meget godt tænke mig lidt respons til layoutet.

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.
Jeg har derfor lavet en ordre-tabel til at holde informationer om hver
enkelt ordre, og dernæst en tabel der hedder timer2003, hvor hver
konsulent har en kolonne, og datoerne udgør rækkerne.
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.
Men når jeg f.eks. vil regne det totale antal timer sammen for 360 dage
med over 100 konsulenter bliver det jo et ret ressourcekrævende
regnestykke for serveren.
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?

Er der ikke nogen som har en smartere måde?

Alle råd modtages med glæde.
//morten

 
 
Jens Gyldenkærne Cla~ (03-02-2003)
Kommentar
Fra : Jens Gyldenkærne Cla~


Dato : 03-02-03 23:04

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.

Morten Abildgaard (04-02-2003)
Kommentar
Fra : Morten Abildgaard


Dato : 04-02-03 00:01

Jens Gyldenkærne Clausen skrev:
[klip]
> 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).
[klip]

Aha-ja. Den udgave havde jeg ikke lige taget med i overvejelserne.
Mange tak for det hurtige svare. Det var lige hvad jeg manglede.

mvh
Morten Abildgaard

Søg
Reklame
Statistik
Spørgsmål : 177552
Tips : 31968
Nyheder : 719565
Indlæg : 6408847
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste