Salut a tous!

voila, j' utilise dans ma base de données un champs TEXT pour afficher ma date au format jj/mm/aa. Je sais , je sais, je n' utilise pas volontairement le champs DATE ou DATTIME et je ne fais pas de timestamp.


Tout fonctionne nickel a part le classement de mes dates.

au lieu d'avoir :

01/01/2011
02/02/2012
01/01/2013
03/03/2013

je me retrouve avec les premiers chiffres seulement pris en compte pour le tri soit:

01/01/2011
01/01/2013
02/02/2012
03/03/2013

Comment pouvoir a la limite lui dire de lire les dates sans les slashs pour tirer le tout, car le probleme est que je ne peux pas faire une chaine de caractere avant d'avoir fait la requete du tri!

Je suis coincé, merci de votre aide!

Ben comme tu le dis toi même, si tu n'utilises pas volontairement de champ date, tu te prives volontairement de toute les fonctions et traitement liés aux dates... Avec un champ texte, ton tri est donc alphabétique au lieu de chronologique...

A noter que même sans les slashes, ton tri ne sera pas correct puisque la date 01012011 sera placé avant le 02012010 puisque 01 est avant 02.

Tu dois pouvoir t'en tirer en découpant ta chaine en sous chaine avec substr() ou substring() pour isoler les deux chiffres du jour, les deux chiffres du mois et les quatre chiffres de l'année, puis trier par année, mois et jour. Quelque chose du genre :

SELECT .... SUBSTR(ton_champ, 1, 2) AS jour, SUBSTR(ton_champ, 4, 2) AS mois, SUBSTR(ton_champ, 6) AS an 
  FROM .... 
  ORDER BY an, mois, jour

(à vérifier pour les index)

Par contre côté performance faut oublier si tu dois gérer de nombreux enregistrements, tes utilisateurs devront se faire une raison et patienter... De mon point de vue, tu as tout intérêt a ajouter un champ date, copier tes données par un update, et travailler avec les bons outils

De mon point de vue, tu as tout intérêt a ajouter un champ date, copier tes données par un update

+1
J'ajouterais même qu'un UPDATE n'aurait en l'occurrence rien de compliqué :

UPDATE ta_table
SET ton_champ_date = CAST(CONCAT(
  SUBSTR(ton_champ_text, 7),
  '-',
  SUBSTR(ton_champ_text, 4, 2),
  '-',
  SUBSTR(ton_champ_text, 1, 2)
) AS DATE);

Ça va transformer un « 04/09/2011 » en « 2011-09-04 » avec le bon type, encore que le CAST dans ce cas là ne soit pas nécessairement indispensable, il faudrait vérifier, je n'ai pas testé, mais c'est la version que j'essayerais en premier. Et comme il n'y a pas de clause WHERE, ça va affecter intégralement toutes les lignes de la table.

Et là tu pourrais disposer de toutes les fonctions natives du SGBD pour trier sur les dates.

J'ajoute que si tu veux récupérer une date « 2011-09-04 » au format « 04/09/2011 », tu disposes avec MySQL de la fonction DATE_FORMAT, ça donnerait ceci :

mysql> SELECT DATE_FORMAT(CAST('2011-09-04' AS DATE), '%d/%m/%Y') as ma_date_fr;
+------------+
| ma_date_fr |
+------------+
| 04/09/2011 |                                                                                                                                                                                                                                                                 
+------------+                                                                                                                                                                                                                                                                 
1 row in set (0.00 sec)

Pour illustrer l'exemple, j'ai fait un CAST sur une chaîne de caractère pour que la valeur soit traitée comme une date. Dans ta requête, remplace par le nom de ta colonne comme ceci :

SELECT DATE_FORMAT(ton_champ_date, '%d/%m/%Y') as ma_date_fr;

Ce sera infiniment plus efficace

ben alors ok, mais je n' ai qu' un champs date, pas un pour le jour, un pour l' année et un pour le mois! Un seul champs date que j' ai passé de TEXT a DATE, ok, je me retrouve maintenant avec des 0000-00-00 partout, gros probleme, mes insertion ne font que des zeros, je ne sais pas pourquoi! Le probleme est que j' utilise un calendrier cliquable en javascript qui me rend une date de ce type jj/mm/aa et pas 0000-00-00.

Comment puis je adapter le champs date pour que quand j' insere dans la base de données ca fonctionne. En passant il s'agit d' un petit script que je fais pour un reseau intranet donc pas de souci de ce coté.


Alors comment faire parce que la je trouve ca plus compliqué du coup!

recupérer une date par exemple en 11/12/2011 =>insertion 2012-11-12 puis affichage ensuite 11/12/2011


Ma solution n'était pas plus simple? Elle fonctionnait, il aurait juste fallu trouver une chaine de caractere pour virer les slashs :/

Ce n'est pas le champ date qu'il faut adapter, c'est la donnée que tu y insères... En php tu peux facilement transformer ta chaine jj/mm/aa en aaaa-mm-jj pour l'insérer en base

Pour le reste :
Quelques petites manipulations avec les dates (PHP/MySQL)

Et si l'on te préconise d'ajouter un nouveau champ de type date pour y transférer tes données au bon format, c'est pour éviter de les perdre en changeant le format de la colonne...

Oui je le savais pour la pertes des données si je modifie un champs.

Je connais aussi les operations possibles (en general) avec DATE, mais justement c'est un choix volontaire, il faut y voir un peu un défi. D'ou la difficulté de la chose.


Bon ben c'est pas grave, je vous remercie pour vos conseils quand meme, c'était sympa, je vais me tournenr vers les chaines de caractere pour supprimer ces slashs

La solution tordue envisageable (en mode « masturbation intellectuelle ») si tu envoies des dates au format jj/mm/aaaa, ce serait en faisant un CAST avec une concaténation de sous-chaines dans ta requête SQL d'insertion, tu iras très largement plus vite avec un str_replace ou un preg_replace en PHP, mais dans le pire des cas, ça pourrait ressembler à quelque chose dans ce genre là :

INSERT INTO ma_table(ma_colonne_date) VALUES(
  CAST(CONCAT(
    SUBSTR('". $ma_var_pgp_date ."', 7),
    '-',
    SUBSTR('". $ma_var_pgp_date ."', 4, 2),
    '-',
    SUBSTR('". $ma_var_pgp_date ."', 1, 2)
  ) AS DATE)
);

Et en cherchant un peu, je suis même sûr qu'on doit pouvoir trouver plus tordu encore