Ik heb de volgende query:
SELECT DISTINCT(persnr), werknr, SUM(o100) as o100, SUM(o125) as o125, SUM(o150) as o150, SUM(o200) as o200, SUM(tvt) as tvt, SUM(vrij) as vrij, SUM(bijz_verlof) as bijz_verlof, SUM(ziekte) as ziekte, lc_bv FROM uren WHERE MONTH(uren.datum)='$_POST[maand]' AND YEAR(uren.datum)='$_POST[jaar]' GROUP BY werknr ORDER BY persnr,datum;
Op zich werkte deze query prima, echter, door een aanpassing moet ik hem wijzigen, maar ik krijg het niet voor elkaar om hem correct te wijzigen.
Eenvoudig gezegd, maar niet mogelijk, zou ik eigenlijk een distinct(persnr,lc_bv) moeten doen, maar distinct accepteert maar 1 veld.
Met de query, krijg ik per persnr de verschillende totalen van de andere velden. Echter, door een aanpassing moet ik nu de verschillende totalen van de andere velden per persnr hebben en dan ook nog eens per lc_bv.
Het is wat moeilijk uitleggen, maar hopelijk begrijpt iemand wat ik bedoel. :P
Als ik deze tabel zo zie, denk ik dat je eerst maar eens moet beginnen met normaliseren en je datamodel opnieuw opbouwen...
`werknr` varchar(50) NOT NULL,
`persnr` varchar(5) NOT NULL,
`afd` varchar(50) NOT NULL,
`afd_chef` varchar(50) NOT NULL,
`hgr_ldng_gev` varchar(50) default NULL,
`peno` varchar(50) default NULL,
`sal_adm` varchar(50) default NULL,
Deze gegevens bijvoorbeeld hoor je al in (een) aparte tabel(len) op te slaan. En daarbij kun je ook altijd aannemen dat zodra jij kolommen gaat nummeren (o110, 0125, 0150, 0200) je datamodel niet juist is.
Klopt, maar eerst moet het maar eens werken, daarna ga ik het beter maken. :)
Precies verkeerd gedacht dus. Als jij met een verkeerd datamodel aan de gang gaat, moet je dat nu veranderen. Je gaat namelijk gegarandeerd op problemen stuiten als je hiermee verder blijft werken!
Ik weet dat het datamodel niet helemaal top is. Maar ik heb qua tijd niet de mogelijkheid dat nog aan te passen.
De velden die je noemt bevatten een id naar een aparte tabel. (in eerste instantie niet, vandaar dat er bijv. nog varchar(50) staat.
Het gaat er mij nu om, om die query goed te krijgen, het datamodel aanpassen zit er qua tijd gewoon niet in. De fout daarin zit hem in het feit dat de doelstelling van het script dat ik schrijf, meermalen tussentijds is veranderd. Ondanks deze tekortkoming werkt het verder wel prima, en worden eventuele fouten wel afgevangen, mijn probleem is nu alleen nog deze query. Als ik dat klaar heb kan ik nog kijken of ik tijd heb om andere tekortkomingen aan te passen, maar dat zal lastig zijn helaas, en is niet mijn keuze. :)
Ik weet dat het datamodel niet helemaal top is. Maar ik heb qua tijd niet de mogelijkheid dat nog aan te passen.
Maar je hebt wel tijd om alle problemen die je nu aan het maken bent (!!!) ook op te gaan lossen?
Daarnaast krijg je de garantie dat er data-inconsistentie op gaat treden, dat gaat je nog veel meer problemen opleveren.
Het is maar waar je zin in hebt...
Nu de boel oplossen (goed datamodel maken) gaat een stuk sneller dan straks het systeem opnieuw bouwen, alle puinhopen opruimen en de data (voor zover mogelijk) opnieuw in te kloppen.
Het is jammer dat jullie reageren alsof het mijn keuze is. :)
Dit is het enige probleem waar ik tegen aanloop, en het aanpassen van een query is m.i. minder werk dat het hele datamodel en al mijn scripts aanpassen. Bovendien, wat Blanche aangeeft is dus al het geval, dus zo erg is het nu ook weer niet. Inmiddels denk ik dat ik achter de juiste query ben:
SELECT persnr, SUM(o100) as o100, SUM(o125) as o125, SUM(o150) as o150, SUM(o200) as o200, SUM(tvt) as tvt, SUM(vrij) as vrij, SUM(bijz_verlof) as bijz_verlof, SUM(ziekte) as ziekte, lc_bv FROM uren WHERE MONTH(uren.datum)='11' AND YEAR(uren.datum)='2006' GROUP BY werknr,persnr,lc_bv ORDER BY persnr,datum;
Dit geeft het resultaat waar ik naar op zoek was.
In ieder geval bedankt voor de reacties. (ik weet dat ze goed bedoeld zijn hoor!)
Wil ik toch nog even op inspringen Wim, het lijkt misschien wat makkelijker om een query snel aan te passen ipv van normalisatie toe te passen maar dat is zeker niet de slimste oplossing. Een goedwerkende database zorgt voor een goed werkend systeem. Als er geen goede database als basis ligt voor een systeem kan er veel dubbel werk gedaan worden en kom je er later pas echt achter dat het toch sneller was om een normalisatie uit te voeren.
Het is eigenlijk gewoon een stap die je meteen uit moet voeren. Een goede basis is het minste werk. Zelf heb ik dit (klik) boek en ben er best tevreden mee, helpt me in ieder geval goede databases te maken.
dat is absoluut waar, maar het is bij mijn opdracht een beetje de soep ingelopen omdat de doelstelling en mogelijkheden van het script een aantal keren tussentijds, zonder tijdig aangeven zijn gewijzigd. We hebben nadelen/voordelen afgewogen, en uiteindelijk besloten het nu eerst zo te laten.
Dit is dus de reden waarom we kiezen voor de "oplossing" om de query aan te passen.
