Het lijkt een erg eenvoudige query, maar ik kom er niet uit.
Zie hier een voorbeeld inhoud van de tabel "tarief".
Deze tabel is gekoppeld aan de tabel "functie" (functie.functieID = tarief.functieID)
Waarom uurtarief niet gewoon in tabel functie? => Stel dat het uurTarief voor een functie aangepast wordt, moet de historie met het oude tarief natuurlijk nog kloppen.
<?php
functieID | uurTarief | ingangsdatum
1 150.00 23-11-2004
1 155.00 18-05-2005
2 120.00 09-02-2004
1 175.00 19-07-2006
3 120.00 21-10-2006
2 135.00 12-04-2004
?>
Graag wil ik de huidige uurtariefen selecteren, dus wil ik het volgende resultaat:
Werkt volgens mij het beste door de MAX in een sub-query te bepalen:
[code]
SELECT
a.functieID,
a.uurTarief,
a.ingangsdatum
FROM
tarief a
WHERE
a.ingangsdatum = (SELECT
MAX(b.ingangsdatum)
FROM
tarief b
WHERE
a.functieID = b.functieID)
@Jeroen:
Helaas draait de webserver op SQL 4.0 en niet 4.1, dus kan geen subquery's aanmaken.
@Robert:
Lastig uit te leggen, maar werkt ook niet. De ingangsdatum is niet altijd gelijk aan de "nieuwste", zoals je in de HAVING neerzet. Als er meerdere ingangsdata bestaan voor een functieID, dan pakt hij gewoon de eerste ingangsdatum (want je groepeerd) en hij pakt de MAX ingangsdatum. Dit is dus niet gelijk.
@Jeroen:
Maar je query werkt wel. Dit is precies wat ik wil hebben, maar de server ondersteunt het niet :(. Misschien zal ik het een en ander gaan voorstellen.
@Klaasjan:
Ik begrijp wat je bedoelt, maar toch vind ik de einddatum overbodig. Overbodigheid lijdt dan weer tot inconsistentie. Je zit dan met 2 data te knoeien die goed op elkaar moeten aansluiten.
Ik zal er over nadenken, want het is wel een oplossing.
@Jeroen:
.....
@Klaasjan:
Ik begrijp wat je bedoelt, maar toch vind ik de einddatum overbodig. Overbodigheid lijdt dan weer tot inconsistentie. Je zit dan met 2 data te knoeien die goed op elkaar moeten aansluiten.
Ik zal er over nadenken, want het is wel een oplossing.....
Volgens mij is dat juist de manier om historie te bewaren.
Je kunt deze nu altijd beeindigen met UPDATE bla SET datum_einde=NOW())
@Robert:
Lastig uit te leggen, maar werkt ook niet. De ingangsdatum is niet altijd gelijk aan de "nieuwste", zoals je in de HAVING neerzet. Als er meerdere ingangsdata bestaan voor een functieID, dan pakt hij gewoon de eerste ingangsdatum (want je groepeerd) en hij pakt de MAX ingangsdatum. Dit is dus niet gelijk.
Ik weet niet of je het hebt getest, maar volgens mij pakt die door de group by elke keer de hoogste datum van een bepaald ID..
Als ik het goed heb (zelf niet getest) dan pakt die een id, van die ID de hoogste datum, en dan daarvan de prijs.
Wat je zei over de ingangsdatum gebruik je toch gewoon de MAX ingangsdatum in je echo, tenminste als die wel de juiste gegevens selecteerd.
@Jan:
Getest, maar ik moet niet op uurtarief groeperen, omdat dat juist steeds verschilt. Het moet echt per functie zijn (per functie de huidige tarieven)
@Klaasjan:
Je hebt wel gelijk. Maar ik wil niet graag met periodes werken, tenzij het gaat om aantoonbare start en einddatum (bijv. deadlines bij een project). Op deze manier moeten alle data op elkaar aansluiten, dit vind ik toch iets te riskie.
Toch lijkt mij jouw manier wel het beste en zal ik deze wel gaan toepassen, bedankt.
@Robert:
Ik had het wel getest (dit doe ik altijd).
Jij zegt:
Als ik het goed heb (zelf niet getest) dan pakt die een id, van die ID de hoogste datum, en dan daarvan de prijs.
Nee, dat is het rare. Hij toont (door het groeperen) niet de hoogste prijs bij de MAX datum. Dat is het probleem. Hij toont de eerste tarief dat ie vind, met de MAX ingangsdatum.
Ik weet niet of je het hebt getest, maar volgens mij pakt die door de group by elke keer de hoogste datum van een bepaald ID..
Als ik het goed heb (zelf niet getest) dan pakt die een id, van die ID de hoogste datum, en dan daarvan de prijs.
En dit is een grove fout van MySQL!
Met het gebruik van GROUP BY geef jij aan dat je de eigenschappen van een bepaalde groep records wilt opvragen. De datum die jij echter wilt opvragen, is geen eigenschap van deze hele groep, maar van een individueel record. Dat gaat dus niet lukken, de database hoort daar ook een foutmelding op te geven. Helaas doet MySQL een gok welke gegevens jij vandaag op het scherm wilt zien... Dat kan dus per keer verschillen. Ik weet het niet zeker, maar volgens mij is er een verband met de laatst aangemaakte records, de auto_increment. Het is in elk geval fout en ga hier dus nooit mee werken, het levert uiteindelijk problemen op.
