[SQL]Selecteer jaar/maand vanuit datetime

[Rommel]

Goedeavond, ben bezig met een onderdeel van een kalender systeem voor een site. Ik heb wat events in de database staan en de datum van de event is opgeslagen als een DATETIME datatype;

id(int(10))	naam(var(45))	datum(datetime)
1	Test event één	2010-01-13 15:00:00
2	Test event twee	2010-02-31 20:00:00
3	Test event drie	2010-03-31 20:00:00

Nu wil ik alle events in een bepaalde maand van een jaar in een array toveren, maar hoe ik dit goed met MySQL selecteer weet ik niet. Via PHP zelf lukt het me wel, maar daar ben ik gauw van afgestapt omdat het me erg omslachtig leek om eerst alle events in de database in een array te stoppen en daarna met PHP te filteren op maand en jaar. (leek mij tenminste vrij omslachtig)

Probeer daarom om zoiets qua query te creeëren:

code:

SELECT id FROM events WHERE datum = jaar = '2010' AND maand = '02'

zodat ik dan volgens de bovenstaande tabel event nummer '2' alleen krijg. Maarja, dat gaat niet echt werken... en in de handleiding van MySQL kan ik ook weinig vinden wat mij op weg kan helpen. owja, de versie van MySQL wat ik heb is 5.0.

Of moet ik bijvoorbeeld 4 tabellen maken om de jaren, maanden, dagen en tijd op te slaan?

[ Voor 1% gewijzigd door Rommel op 02-01-2010 21:01 . Reden: MySQL versie erbij ]

[Verwijderd]

Gebruik gewoon de date/time functions. Je moet vooral niet meerdere kolommen gebruiken om datum/tijd op te slaan.

WHERE MONTH(datum) = 2 AND YEAR(datum) = 2010

[ Voor 17% gewijzigd door Verwijderd op 02-01-2010 21:01 ]

[Rommel]

Verwijderd schreef op zaterdag 02 januari 2010 @ 20:59:
Gebruik gewoon de date/time functions. Je moet vooral niet meerdere kolommen gebruiken om datum/tijd op te slaan.

WHERE MONTH(datum) = 2 AND YEAR(datum) = 2010

Goh, wat logisch eigenlijk achteraf, *kan mezelf wel voor het hoofd slaan* THX Cheatah het werkt!

Nee, dat ik datum/tijd niet in meerdere kolommen moet opslaan leek mij ook niet erg handig.

[ACM]

En als je een index wilt kunnen gebruiken zou ik een bereik opgeven...

WHERE datum >= '2010-02-01' AND datum < '2010-02-01' + INTERVAL 1 MONTH

[GlowMouse]

ACM schreef op zaterdag 02 januari 2010 @ 21:59:
En als je een index wilt kunnen gebruiken zou ik een bereik opgeven...

WHERE datum >= '2010-02-01' AND datum < '2010-02-01' + INTERVAL 1 MONTH

En voor de leesbaarheid kun je nog BETWEEN gebruiken.
_{ACM: zie je MyAT op FOK!, had nog wat geplaatst over update-queries bij innodb}

[ACM]

GlowMouse schreef op zaterdag 02 januari 2010 @ 22:06:
En voor de leesbaarheid kun je nog BETWEEN gebruiken.

't "nadeel" van between in dit geval is dat ie de laatste seconde of dag van het bereik (afhankelijk van of je date of datetime hebt) ook meeneemt, dus dat maakt het iets lastiger om het hele datum-processing-gedoe aan de database over te laten.

[cariolive23]

ACM schreef op zondag 03 januari 2010 @ 14:21:
[...]

't "nadeel" van between in dit geval is dat ie de laatste seconde of dag van het bereik (afhankelijk van of je date of datetime hebt) ook meeneemt, dus dat maakt het iets lastiger om het hele datum-processing-gedoe aan de database over te laten.

Lastiger? Eén blik in de handleiding is voldoende:

expr BETWEEN min AND max

If expr is greater than or equal to min and expr is less than or equal to max, BETWEEN returns 1, otherwise it returns 0.

Kinderachtig eenvoudig dus: (groter dan of gelijk aan min) en (kleiner dan of gelijk aan max). Die laatste seconde en/of dag zal geen probleem zijn.

[Janoz]

cariolive23 schreef op maandag 04 januari 2010 @ 09:28:
[...]

Lastiger? Eén blik in de handleiding is voldoende:

[...]

Kinderachtig eenvoudig dus: (groter dan of gelijk aan min) en (kleiner dan of gelijk aan max). Die laatste seconde en/of dag zal geen probleem zijn.

Werkelijk?

Wil je alles uit december en vul je voor de max 1 januari 2010 00:00:00 in dan heb je toch echt een seconde lang items die eigenlijk toch echt bij Januari horen in je lijst zitten. Aangezien de min en de max ook true opleveren bij equals krijg je dus dat data bij meerdere maanden kan gaan horen en dus dubbel meegeteld gaat worden.

Bij range vergelijkingen is het normaal voor de hand liggender dat er constructies als

min <= val < max

wordt gebruikt om overlap in intervallen te voorkomen.

[cariolive23]

@Janoz: ACM stelt dat BETWEEN lastig is, dat is het niet, je kunt zo lezen wat het doet. En BETWEEN doet dus een (groter dan/gelijk aan) en een (kleiner dan/gelijk aan) vergelijking. Wanneer dit niet is wat je nodig hebt, de genoemde seconde, dan moet je geen BETWEEN gebruiken. Daar is toch niets lastigs aan? Het is haarfijn uitgelegd, dat kan geen probleem zijn.

Databases kunnen dit soort klusjes prima oplossen maar het is wel aan jou om de juiste vergelijkingen op te stellen. Wanneer jij een fout maakt in je query/code, dan kan geen enkele database/programmeertaal daar iets aan veranderen. Poep in, poep uit!

[Creepy]

Dat is toch precies het punt van ACM?

[Janoz]

ACM stelt dat between in deze situatie lastig is omdat er een kans bestaat dat het niet de juiste gegevens op gaat leveren. Als je between gebruikt is de laatste seconde wel een probleem en kun je hem dus niet gebruiken. Het feit dat jij stelt dat 'de laatste seconde' dus geen probleem is geeft al aan dat het toch iets lastiger is dan je denkt. Die aanname is namelijk fout (tenminste, wanneer ik die opmerking interpreteer als een 'je kunt between dus gewoon gebruiken want de laatste seconde levert geen probleem op')

Mijn MENING is dat de gekozen implementatie van between niet de meest voor de hand liggende. Dat blijkt wel weer uit deze discussie. Dat iets keurig in een handleiding uitgelegd wordt betekend nog niet automatisch dat het niet lastig is. Als ik een auto ontwerp en keurig in de handleiding zet dat je het stuur naar rechts moet draaien om linksaf te slaan dan maakt die uitleg het toch ook niet ineens niet lastig?