ORDER BY datum in string vorm
Ik sla data (datums) op als string om bepaalde redenen.
11 november 2012 om 14:30 sla ik zo op:
2012,11,23,14,30
Is er een mogelijkheid om binnen SQL het toch als datum te 'zien' en zo 5 records te pakken, beginnend bij de datum die het dichtst bij vandaag ligt?
Tim van Norde op 08/05/2012 22:18:31:
Ik sla data (datums) op als string om bepaalde redenen.
Zonder de redenen te weten denk ik toch zo arrogant te kunnen zijn om te zeggen dat dat dus niet verstandig is. De oplossing van je probleem begint (het makkelijkst) bij dit aan te passen en het wel gewoon als datum op te slaan.
Erwin H op 08/05/2012 22:30:16:
Zonder de redenen te weten denk ik toch zo arrogant te kunnen zijn om te zeggen dat dat dus niet verstandig is. De oplossing van je probleem begint (het makkelijkst) bij dit aan te passen en het wel gewoon als datum op te slaan.
Tim van Norde op 08/05/2012 22:18:31:
Ik sla data (datums) op als string om bepaalde redenen.
Zonder de redenen te weten denk ik toch zo arrogant te kunnen zijn om te zeggen dat dat dus niet verstandig is. De oplossing van je probleem begint (het makkelijkst) bij dit aan te passen en het wel gewoon als datum op te slaan.
Helemaal mee eens.
Maar als ik het goed heb pakt het nu ook data wat in het verleden ligt. Valt dit nog op te lossen of moet ik er echt een Date veld van gaan maken?
Tim van Norde op 08/05/2012 23:24:15:
of moet ik er echt een Date veld van gaan maken?
Of het moet is helemaal aan jou zelf.
Er word alleen aangeraden om hier een date veld van te maken in plaats wat jij wilt.
Je geeft eigenlijk zelf al aan dat je nu veel dingen moet aanpassen. Het lijkt mij dat je dan beter nu even die dingen kunt aanpassen. Want stel?
Je krijgt dit werkend wat je nu wilt. Helemaal leuk en aardig natuurlijk.
Maar nu wil je het misschien dingen later toch anders weer geven of je wilt het geen verder uitbreiden. En je komt weer met deze date's te zitten. Als je dan er achter komt dat je het echt anders moet gaan doen, dan ben ik bang dat je dan een blauwe plek voor je voorhoofd krijgt (De wel bekende klap voor de kop).
Want hoeveel moet je dan aanpassen? En dan heb ik het niet over de al reeds toegevoegde rows in je database die dan bijna op datum onbruikbaar worden.
Daarom sluit ik mij ook aan bij de eerder advies die gegeven is.
Maak er een date veld van en laat Mysql het werk doen zoals het eigenlijk ook hoort.
Je kunt later altijd het gewenste result terug halen en in php weer geven zoals je het wilt hebben.
- Een Date veld gebruiken
- Alle waardes in aparte velden stoppen, dus een year-, month-, day-, hour-, minute- veld.
Wat je nu hebt, meerdere waardes in 1 veld stoppen gescheiden door komma's, is iets wat totaal niet wordt aangeraden. Die 2e optie is natuurlijk veel te omslachtig en dus zul je de 1e 'moeten' gebruiken.
Je hoeft natuurlijk dit formaat niet met de hand aan te passen. Je kan ook een scriptje schrijven die 2012,11,23,14,30 omschrijft naar 2012/11/23 14:30:00.
Ik heb in elk geval nog nooit een echt goede reden gezien om data in strings op te slaan in plaats van echte DATETIME velden.
Wouter J op 09/05/2012 08:07:03:
... Je kan ook een scriptje schrijven die 2012,11,23,14,30 omschrijft naar 2012/11/23 14:30:00.
Code (php)
Gewijzigd op 09/05/2012 10:27:44 door Kris Peeters
Corrigeer me even als ik er langs zit.
En de - of / mag volgens mij (weet ik niet zeker) elk teken zijn en mag je ook weglaten: YYYYMMDDHHIISS
@Wouter, dat is helder dank je.
Hartstikke bedankt allemaal voor de tips, maar voor nu houd ik het even op een string. Kan iemand mij tips geven over hoe ik mijn vorig geplaatste stukje code zo aan kan passen dat het werkt?
Het is me nog steeds niet gelukt, ik wil het voorlopig nog even in string form houden. Zou iemand mij kunnen helpen met mijn vorige vraag? (vorige post)
Of kan je misschein toch eens die "bepaalde redenen" opnoemen
Gewijzigd op 11/05/2012 09:58:15 door Kris Peeters
Tim van Norde op 11/05/2012 00:15:31:
Het is me nog steeds niet gelukt, ik wil het voorlopig nog even in string form houden. Zou iemand mij kunnen helpen met mijn vorige vraag? (vorige post)
Dan niet. Het spijt me, maar de goede oplossing is gegeven. Als je die niet wil gebruiken dan lijkt het erop dat je te eigenwijs bent om het aan te nemen. Of.... je moet inderdaad de redenen geven waarom niet. Maar als de eerste conclussie geldt dan mag je zelf verder zoeken. Dat is namelijk een stuk lastiger en gaat dus veel meer tijd kosten. Waarom verwacht je dat wij dat voor je gaan doen als de echte oplossing al gegeven is?