Je kan de form frm_uitvoerder_uren bekijken als een urenbriefje/timesheet. Zo dienen wij het ook door te geven naar ons sociaal secretariaat. m.a.w. deze lopen parallel.
...
Alleen het probleem stelt zich dan als er meerdere uur-types per dag zijn.
Hoe dit dan op te lossen?
Je snapt nog steeds niet (helemaal) waar ik heen wil, zou ik deze db zelf ontwerpen. Terwijl jouw verhaal voor de volle 100% mijn concept ondersteunt. Maar jij ziet dat blijkbaar niet, want jij vindt het geen goed idee.
Juist door de gegevens correct op te slaan, bereik je een optimale gegevensstructuur. Ik zeg helemaal niet dat je de urenvelden moet inkorten, vervangen of anders interpreteren. Ik zeg alleen dat je ze moet ‘normaliseren’.
Neem je tweede zin: jij gaat uit van de
output als basis voor de
input. Foute gedachte, moet je nooit doen. Je moet bij het
ontwerpen van je database uiteraard rekening houden met, of zelfs uitgaan van de output, maar het format daarvan mag nooit bepalend zijn voor je input. Dat zijn zelfstandige gegevens binnen de database. Je data moet zodanig zijn gestructureerd dat je de gewenste output te allen tijde kunt produceren. Daarom moet je bij het ontwerpen van een database ook altijd de vraag stellen wat er uiteindelijk uit moet rollen. En daarbij zelfs rekening houden met eventuele toekomstige vragen, indien mogelijk.
Maar het mag nooit zo zijn dat jij, omdat een bepaalde output in een bepaalde vorm wordt verwacht, dan maar tabellen gaat maken waarin die exacte output één-op-één is gekopieerd. Al was het maar omdat je bij een eerstvolgende aanpassing van die output je complete tabel opnieuw moet aanpassen.
Wat ik zou doen is dus een tabel maken voor de verschillende categorieën met daarin alle aspecten die dat tarief bepalen. Heb je met verschillende tarieven per categorie te maken, dan kun je die ook nog in een aparte tabel zetten, of, als het simpel is, in de categorie tabel. Denk aan een categorie die voor een complete werkdag 1 tarief heeft, terwijl je ook een categorie hebt die aparte tarieven heeft voor dag, avond en nacht. Al die aspecten moet je vast kunnen leggen, en op kunnen roepen indien van toepassing.
Daarnaast heb je het ‘probleem’ zoals je het zelf omschrijft dat een persoon meerdere activiteiten op een dag doet, en dat je die allemaal moet registreren.
Juist op dit gebied is een genormaliseerde tabel de beste oplossing; bij zo’n constructie maakt het niet uit of iemand op een dag één activiteit uitvoert, of 20. Je maakt namelijk voor elke activiteit een apart record aan. Maar ook nooit meer dan dat er activiteiten voor die persoon op die dag vastgelegd moeten worden. Hoe hoog is de kans dat iemand op 1 dag 20 verschillende activiteiten uitvoert? Lijkt mij niet zo heel hoog. Maar dan nog: 20 records invullen is totaal niet te vergelijken met een tabel waarin voor diezelfde hoeveelheid gegevens
121 velden beschikbaar zijn. In dit voorbeeld laat je er dus sowieso al 101 leeg. Over verspilling gesproken!
Nog een voorbeeld: jij legt vast hoeveel uren iemand aan 1 activiteit besteedt. Dat kan voldoende zijn, maar voor hetzelfde geld wil het management van jou een keer een overzicht (grafiek) van de activiteiten gerelateerd aan het dagdeel waarin ze worden uitgevoerd. Jij kan dat nooit leveren, omdat jij alleen het aantal uren
per dag kan invullen. In mijn oplossing leg je elke activiteit vast met een begin- en een eindtijd, en je kunt dat overzicht dus te allen tijde maken. Je bent gewoon veel flexibeler.
OK, komen we bij het meest heikele punt, en de reden (vermoed ik) dat je het zo hebt gemaakt. Hoe voer ik die gegevens dan zo makkelijk mogelijk in? Als je een aparte tabel gebruikt voor de input, dan kun je dat niet invoeren m.b.v. een ‘Excel’ achtig formulier zoals je nu gebruikt. Je moet immers voor elke registratie een apart record maken, en dat doe je doorgaans op een doorlopend formulier. Daarbij kun je een hele hoop automatiseren, zoals het standaard invullen van de medewerker en de dag, zodat je alleen de tijd en de categorie hoeft in te vullen, maar zelfs dan ziet het er minder ‘overzichtelijk’ uit als je gewend bent. Dat is enerzijds een stukje gewenning, anderzijds aanleren dat je het overzicht op een ander moment genereert: als je klaar bent met invoeren. Want als de gegevens eenmaal zijn vastgelegd, dan kun je met standaard rapporten en formulieren de gewenste output bekijken of versturen.
Kies je voor een systeem dat lijkt op de huidige structuur, dus alleen de uren per dag invoeren, dan wordt het zelfs nog iets makkelijker (voor de gebruiker, niet voor de bouwer
) omdat je dan het invoerformulier kunt gebruiken dat je nu ook hebt. Alleen dan niet gekoppeld aan een tabel (de velden bestaan immers niet meer) maar als niet-afhankelijk formulier. Je vult dan de gewenste uren voor de gewenste dagen in, zoals je nu ook doet. Alleen heb je dan een procedure nodig die, op basis van de ingevulde uren, records aanmaakt voor die uren en dagen. Zo’n procedure is niet eens moeilijk; kwestie van een loop maken die m.b.v. een recordset alle ingevulde velden met de juiste categorie toevoegt aan je tabel. Ook hiervoor geldt: heb je 47 tekstvakken ingevuld voor een week, dan krijg je 47 records in de tabel. Aan je systeem (en je output; je kunt nu heel simpel een overzicht maken met een draaitabel) verandert dus eigenlijk helemaal niks. Alleen zijn al je problemen opgelost.
Denk er eens over na, zou ik zeggen.
