VNC stopt er mee :(
Distinct 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
kzal ff probere te puzzelen
is lc_bv een getal of??
geef de opbouw van je tabel is..
misschien is er iets veel makkelijkers
totaal_o100
lc_bv is een getal idd.
Dit is de tabel:
CREATE TABLE `uren` (
`id` int(11) NOT NULL auto_increment,
`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,
`datum` date NOT NULL,
`o100` char(4) default NULL,
`o125` char(4) default NULL,
`o150` char(4) default NULL,
`o200` char(4) default NULL,
`tvt` char(4) default NULL,
`vrij` char(4) default NULL,
`bijz_verlof` char(4) default NULL,
`lc_bv` char(6) default NULL,
`ziekte` char(4) default NULL,
`reden` varchar(25) default NULL,
`akkoordwg` char(10) default NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1 AUTO_INCREMENT=3549 ;
@Klaasjan Boven
Klopt, maar eerst moet het maar eens werken, daarna ga ik het beter maken. :)
`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.
Quote:
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!Klopt, maar eerst moet het maar eens werken, daarna ga ik het beter maken. :)
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. :)
Quote:
Maar je hebt wel tijd om alle problemen die je nu aan het maken bent (!!!) ook op te gaan lossen?Ik weet dat het datamodel niet helemaal top is. Maar ik heb qua tijd niet de mogelijkheid dat nog aan te passen.
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.
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!)
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.
Maar goed, wat ik je dan nog wel even mee wil geven voor deze query is dat je je aliassen niet slim gekozen hebt. Je gebruikt namelijk voor een alias dezelfde naam als de kolomnaam (SUM(o100) AS o100), en ook dat kan problemen op gaan leveren. Verander de alias dus bijvoorbeeld even in o100_totaal...
Je hebt me wel degelijk overtuigd, ik zou het liever ook anders doen, maar die tijd wordt me niet gegeven. :)
Die aliassen ga ik nog wel iets aan doen.