Post by Thierry MattheyDet som jeg ser som en virklig svakhet i etiming er en database som
blander statisk loeperinformasjon og dynamisk data (MTR'er) ... gaar
databasen i vasken (har oppleved selv) blir det meget vanskelig aa huske
alle manuelle endringene. Jeg mener at det er bedre aa skille statisk,
MTR-datane og maaten man lager resultater, da kan du lage dem omigjen
senere.
Ja!
Jeg lager med vilje slike systemer som dette (også i jobb-sammenheng!)
med uavhengige input-filer for forskjellige typer data, i
orienterings-sammenheng så laget jeg ett skript for å generere
sammenlagt-lister for bedrifts-løpene i Oslo.
I stedet for å gå inn og rett opp de enkelte resultat-filene (som alle
er i html) ved en manuell korreksjon, så lagde jeg i stedet en separat
korreksjons-fil som kun inneholder tillegg/endringer til det som de
enkelte resultat-filene viser.
På ett generelt O-system så ville jeg i dag starte med en (My)SQL
database, med generelle tabeller over løpere/klubber/brikker osv.
PÅ hvert enkelt løp lages en ny DB, med tabeller over klasser, løyper,
starttider og påmeldte (ref tilbake til løper-DB).
Alle EMIT/MTR data lagres rått i en egen tabell, og alle manuelle
endringer/korreksjoner gjøres på en egen endrings-tabell.
På denne måten blir aldri noe slettet, og det er alltid mulig å kjøre om
igjen etter en vilkårlig oppdatering av basis-tabellene.
Det eneste jeg lurer litt på er om det er riktig å bruke EMIT brikke-nr
som primær nøkkel for å binde tabellene sammen, da det har vist seg at
relativt mange løpere kommer til å bruke mer enn en brikke i løpet av en
sesong (glemt brikke, stafett, byttet brikke), og bruk av brikke som
nøkkel vil gjøre det umulig å kjøre gamle resultater om igjen når
løperen har byttet brikke i mellomtiden.
Terje
--
- <***@hda.hydro.com>
"almost all programming can be viewed as an exercise in caching"
