[php] sorteren bij datum

[Slaughterer]

Ik heb een gastenboek op delete en heb ervoor gekozen te sorteren op datum.

De code in de body is

PHP-code:

<table align="center" border="1" width="80%">
 <tr>
  <td bgcolor="black">DATUM</td>
  <td bgcolor="black">NAAM</td>
  <td bgcolor="black">MENING</td>
  <td bgcolor="black">COMMENTAAR</td>
 </tr>

 <?php
  $db = mysql_connect();
  $sql="SELECT DATE_FORMAT(datum,'%d-%m-%Y %H:%i:%s') AS datum, naam, mening, commentaar FROM gastenboek ORDER by datum DESC";
  $res=mysql_query($sql, $db);
  while ($ligne = mysql_fetch_object ($res))
  {
   print "<tr>";
   print "<td>$ligne->datum</td>";
   print "<td>$ligne->naam</td>";
   print "<td>$ligne->mening</td>";
   print "<td>$ligne->commentaar</td>";
   print "</tr>";
  }
  mysql_free_result ($res);
  mysql_close($db);
 ?>

</table>

Zoals je op de site kan zien staan de data echter door elkaar.

Wat doe ik fout en hoe kan ik ervoor zorgen dat het wel goed wordt gesorteerd?

[chatfreak2002]

PHP-code:

  $sql="SELECT DATE_FORMAT(datum,'%d-%m-%Y %H:%i:%s') AS datum, naam, mening, commentaar FROM gastenboek ORDER by datum ASC"; 


dit misschien?

nou..
ik zou de datum laten opslaan als unixtimestamp/epoch http://nl.php.net/date

En daarna die 'getalletjes' omzetten naar leesbare tijd..
is altijd erg netjes dan

[McMotion]

McLaren schreef:
nou..
ik zou de datum laten opslaan als unixtimestamp/epoch http://nl.php.net/date

En daarna die 'getalletjes' omzetten naar leesbare tijd..
is altijd erg netjes dan

doet hij toch ook?

[McMotion]

Slaughterer schreef:

PHP-code:

$sql="SELECT DATE_FORMAT(datum,'%d-%m-%Y %H:%i:%s') AS datum, naam, mening, commentaar FROM gastenboek ORDER by datum DESC"; 


maak daar eens van:

PHP-code:

$sql="SELECT DATE_FORMAT(datum,'%d-%m-%Y %H:%i:%s') AS stringdatum, naam, mening, commentaar FROM gastenboek ORDER by datum DESC"; 


[Chimera]

McLaren schreef:
nou..
ik zou de datum laten opslaan als unixtimestamp/epoch

Klok-klepel. Bovendien HEEFT hij de datum al als DATE(TIME) opgeslagen, anders zou DATE_FORMAT hoogstwaarschijnlijk nieteens werken.

[Harrie]

als je gewoon op id DESC sorteert heb je hetzelfde effect (normaal gesproken)....

[Slaughterer]

Harrie schreef:
als je gewoon op id DESC sorteert heb je hetzelfde effect (normaal gesproken)....

hm...dat ik er zelf niet opgekomen ben...

Bedankt

[McMotion]

Slaughterer schreef:


hm...dat ik er zelf niet opgekomen ben...

Bedankt

ja NORMAAL gesproken jah als alles netjes via het script is ingevoerd.. maar het is veel netter en duidelijker om het gewoon op datum te sorteren.. werkte dat wat ik zei niet dan?

[Slaughterer]

McMotion schreef:


ja NORMAAL gesproken jah als alles netjes via het script is ingevoerd.. maar het is veel netter en duidelijker om het gewoon op datum te sorteren.. werkte dat wat ik zei niet dan?

Dat heb ik niet geprobeerd. Het leek me alleen niet kunnen. Je noemt die variabele 'stringdatum', maar die bestaat in dit geval naar mijn mening helemaal niet. De variabele heet 'datum', die heb ik hiervoor al benoemd, indien deze vervolgens 'stringdatum' wordt genoemd wordt deze niet herkend neem ik aan.

[Chimera]

Slaughterer schreef:


Dat heb ik niet geprobeerd. Het leek me alleen niet kunnen. Je noemt die variabele 'stringdatum', maar die bestaat in dit geval naar mijn mening helemaal niet. De variabele heet 'datum', die heb ik hiervoor al benoemd, indien deze vervolgens 'stringdatum' wordt genoemd wordt deze niet herkend neem ik aan.

*zucht*

Het hele punt is nu juist dat je dan WEL een var genaamd stringatum hebt. Deze kun je weergegeven, terwijl gewoon op datum gesorteerd wordt.

[Harrie]

McMotion schreef:
ja NORMAAL gesproken jah als alles netjes via het script is ingevoerd.. maar het is veel netter en duidelijker om het gewoon op datum te sorteren.. werkte dat wat ik zei niet dan?

duidelijker en netter?!
helemaal niet, dat maakt geen ene fluit uit.

en met normaal gesproken bedoelde ik, dat je auto_increment op je id hebt gezet.. en je scripts niet met de id's gaan kloten..

[Chimera]

Harrie schreef:


duidelijker en netter?!
helemaal niet, dat maakt geen ene fluit uit.

Absoluut wel. Als je op datum wilt sorteren, sorteer je op datum, en niet op je ID. Er is nl. niks dat een DB verbiedt IDs te recyclen. Bovendien is het gewoon een kwestie van onderhoudbaarheid en leesbaarheid.

[McMotion]

Harrie schreef:
duidelijker en netter?!
helemaal niet, dat maakt geen ene fluit uit.

als jij een maand later je code terugleest, wat zou je dan makkelijker kunnen begrijpen? 'ORDER BY datum' of 'ORDER BY ID'? nu begrijp je wel wat je met die laatste wil bereiken, maar wat als je een maand niet naar je code hebt gekeken? of bijvoorbeeld mensen die jouw code moeten gaan implementeren ofzo?
een ID moet je alleen zien als een verwijzing naar je record, een of ander abstract datatype wat je helemaal niet WIL kennen

[Slaughterer]

Chimera schreef:


*zucht*

Het hele punt is nu juist dat je dan WEL een var genaamd stringatum hebt. Deze kun je weergegeven, terwijl gewoon op datum gesorteerd wordt.

*zucht*

deze stingdatum bestaat niet. Dan zou ik deze ook moeten creeren als de gegevens naar de database worden wegeschreven, maar dat is niet gedaan. Dat zou ik dan ook moeten aanpassen, maar dat melde je niet.

Als ik jouw manier gebruik, dan verdwijt de datumaanduiding in het gastenboek

[Manuzhai]

Slaughterer schreef:
deze stingdatum bestaat niet. Dan zou ik deze ook moeten creeren als de gegevens naar de database worden wegeschreven, maar dat is niet gedaan. Dat zou ik dan ook moeten aanpassen, maar dat melde je niet.

Je blaat uit je nek. McMotion schreef een query waar hij een DATEFORMAT() AS stringdatum in de SELECT heeft staan. Dat wil zeggen dat het resultaat van de DATEFORMAT functie op het veld "datum" wordt meegegeven in de resultset als stringdatum: in die resultset heb je dan dus een "stringdatum" veld.

[Chimera]

Slaughterer schreef:

Dat zou ik dan ook moeten aanpassen, maar dat melde je niet.

Goed. Weer iemand die in het vervolg lekker ZELF z'n problemen op mag lossen.

Als iemand je de enige juiste oplossing aandraagt, mag je daar best eens even wat vriendelijker op reageren. Je kunt moeilijk verwachten dat men je alles voor gaat kauwen.

[Slaughterer]

Manuzhai schreef:
Je blaat uit je nek. McMotion schreef een query waar hij een DATEFORMAT() AS stringdatum in de SELECT heeft staan. Dat wil zeggen dat het resultaat van de DATEFORMAT functie op het veld "datum" wordt meegegeven in de resultset als stringdatum: in die resultset heb je dan dus een "stringdatum" veld.

Lijkt me handig als ie dat dan even gelijk vermelde. Niet iedereen is zo handig met php.

[Harrie]

Chimera schreef:
Absoluut wel. Als je op datum wilt sorteren, sorteer je op datum, en niet op je ID. Er is nl. niks dat een DB verbiedt IDs te recyclen. Bovendien is het gewoon een kwestie van onderhoudbaarheid en leesbaarheid.

leesbaarheid/onderhoudbaarheid :

==================================
// Op datum gaan sorteren dmv id
$sql = "SELECT * FROM aap ORDER BY id DESC";
==================================

dat scheelt dus niet veel..

bij een gastenboek heb je bv int(6) (unique)(auto_increment), dan gaat de database niet 2x dezelfde id invoegen als 1 id van dezelfde waarde is verwijderd.

[Chimera]

Harrie schreef:

dat scheelt dus niet veel..

Ja dat doet het wel. Een andere programmeur gaat zich dan afvragen waarom er niet gewoon op datum gesorteerd wordt, en gaat er dan dus vanuit dat dat om een of andere reden niet kan.

Goede code heeft geen uitleg nodig, comment binnen functies zijn 9 van de 10 keer gewoon fout. Code moet zo netjes zijn, dat je geen commentaar nodig hebt.

En nogmaals: Het is voor een DB niet verboden IDs te recyclen. Ook worden IDs vaak random-uniek i.p.v. sequentieel gegenereed.

[McMotion]

Harrie schreef:
bij een gastenboek heb je bv int(6) (unique)(auto_increment), dan gaat de database niet 2x dezelfde id invoegen als 1 id van dezelfde waarde is verwijderd.

en stel dat je nou bijvoorbeeld twee guestbooks hebt waarvan je de reacties bij elkaar wil zetten zodat ze in 1 tabel komen te staan... dan krijg je dubbele ID's... niet echt handig dus... en ok, je zou de ID weg kunnen laten uit de query, zodat hij de eerst volgende neemt, maar dan klopt de sortering niet meer
of stel dat je om wat voor reden dan ook een reactie met de hand wil toevoegen van een datum die je zelf opgeeft in je query.. dan mag jij heel hard hopen dat de datum tussen de huidige datum en de datum van de laatste post ligt, anders klopt de sortering ook niet meer

[Harrie]

Chimera schreef:

Ja dat doet het wel. Een andere programmeur gaat zich dan afvragen waarom er niet gewoon op datum gesorteerd wordt, en gaat er dan dus vanuit dat dat om een of andere reden niet kan.

Goede code heeft geen uitleg nodig, comment binnen functies zijn 9 van de 10 keer gewoon fout. Code moet zo netjes zijn, dat je geen commentaar nodig hebt.

En nogmaals: Het is voor een DB niet verboden IDs te recyclen. Ook worden IDs vaak random-uniek i.p.v. sequentieel gegenereed.

een andere programmeur? ja het is voor jezelf.. een andere programmeur doet nu even niet ter zake.

comment 9 van de 10 x fout? waarom?!

PHP-code:

// sorteren op datum 


is heel wat makkelijker lezen dan

PHP-code:

$sql = "SELECT blabla"; 


hoor.. het wordt er dus overzichtelijker op, ook al is de functie nog zo duidelijk..

een db geeft geen 2 dezelfde id waarden weg hoor.

[McMotion]

heheheheh jah zeker heel wat overzichtelijker hoor gewoon je code in commentaar omzetten wat vervelend ook dat je bij duidelijke code geen commentaar MAG zetten he Harrie?

[Harrie]

McMotion schreef:
heheheheh jah zeker heel wat overzichtelijker hoor gewoon je code in commentaar omzetten wat vervelend ook dat je bij duidelijke code geen commentaar MAG zetten he Harrie?

het gaat er toch om dat jíj er makkelijk mee kan werken?
dus als jíj er makkelijker mee kan werken, doe je dat toch?
Want ik wil maar niet snappen dat het niet mag..