Voor een bepaald script moeten er gegevens uit de database gehaald worden. Per record is er ook een variabele (datum) datum_van en datum_tot. Bij het ophalen moet de query controleren of de huidige datum van vandaag zich bevindt tussen deze twee data. Als dat zo is mag het record uit de database worden gehaald.
Op dit moment heb ik het zo:
<?php
$query = mysql_query("SELECT *, DATE_FORMAT(datum_van, '%d-%m-%Y') AS datum_van, DATE_FORMAT(datum_tot, '%d-%m-%Y') AS datum_tot FROM data WHERE adres_id = '".$adres[id]."' AND ((periode = '1') OR ((periode = '4') AND (datum_van > NOW()) AND (datum_tot > NOW()))) ORDER BY id DESC") or die(mysql_error());
?>
Nu werkt dit wel met periodes die beginnen en eindigen in 2008 maar de periodes die beginnen in 2007 en eindigen in 2008 worden niet opgehaald. Hoe kan ik dit oplossen?
SELECT
*,
DATE_FORMAT(datum_van, '%d-%m-%Y') AS datum_van,
DATE_FORMAT(datum_tot, '%d-%m-%Y') AS datum_tot
FROM
data
WHERE
adres_id = '".$adres[id]."'
AND (
(periode = '1')
OR (
(
periode = '4'
)
AND (
datum_van > NOW()
)
AND (
datum_tot > NOW()
)
)
)
ORDER BY
id DESC
Wat een query zeg! Vooral het overvloedige gebruik van haakjes maakt het er niet leesbaarder op. Een groot deel kun je zo weggooien, ze staan niks te doen.
Dan het probleem: Jouw aliassen zijn het zelfde als de originelen:
datum_van AS datum_van
en
datum_tot AS datum_tot
Alleen staat er nu iets anders in deze kolom, een opgemaakte datumstring. En deze kun je niet meer vergelijken met NOW(), die heeft namelijk een ander formaat. Daarnaast kun je niet met NOW() aan de slag, die heeft ook een tijd. Je zult dus met CURRENT_DATE() moeten vergelijken.
Ps. Sorteren op id is kansloos, een id is niks, betekent niks en je kunt er eigenlijk niks mee. Behalve een uniek record aanwijzen. Jouw sortering kan dus nergens op slaan. Sorteer op een ander veld of sorteer niet.
@pgFrank:
Wat maakt het eigenlijk uit dat de aliassen gelijk zijn. Ik heb namelijk ook geprobeerd deze te veranderen maar ik kreeg hetzelfde resultaat.
Ik ga de CURRENT_DATE morgen maar eens proberen. Dan moeten deze waarschijnlijk in oud formaat blijven staan (YYYY-MM-DD)?
Dat sorteren op ID maakt juist wel wat uit, namelijk de volgorde van invoeren. En waarom zou je er niet op mogen sorteren. Kansloos vind ik daarom een slecht gekozen woord, dit kun je alleen zeggen wanneer je weet met wat voor script je te maken hebt, lijkt mij.
@Jan Koehoorn:
Bedankt, ik ga het eens proberen :)
@pgFrank:
Wat maakt het eigenlijk uit dat de aliassen gelijk zijn. Ik heb namelijk ook geprobeerd deze te veranderen maar ik kreeg hetzelfde resultaat.
De inhoud van de alias is anders dan het origineel. Door dezelfde naam te gebruiken, ga je in de knoop komen, je kunt bv. niet meer sorteren op een datum, dd-mm-yyyy is tenslotte geen datum meer.
Dat sorteren op ID maakt juist wel wat uit, namelijk de volgorde van invoeren. En waarom zou je er niet op mogen sorteren. Kansloos vind ik daarom een slecht gekozen woord, dit kun je alleen zeggen wanneer je weet met wat voor script je te maken hebt, lijkt mij.
Nee, helaas, het is volkomen kansloos, nutteloos en waardeloos. Ga maar eens een backup terugzetten in een database waarbij je de auto_increment hebt gereset. Dan blijken ineens de oude records hogere id's te hebben dan de nieuwere records. Ze moeten tenslotte worden toegevoegd aan de bestaande gegevens, die (gedeeltelijk?) dezelfde id's hebben. Bij het terugzetten van de oude gegevens zul je dus nieuwe id's moeten aanmaken. Dat geeft niks, een id betekent tenslotte helemaal niks. Met een id kun je UITSLUITEND een uniek record aanwijzen, ook als jij vindt van niet. Het is helaas niet anders.
Wil jij de ouderdom van een record opslaan, heb je een datumtijdstempel nodig in de tabel. Dat is de enige juiste oplossing, met andere 'oplossingen' hou jij jezelf voor de gek.
