Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2004
    Messages
    79
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2004
    Messages : 79
    Points : 17
    Points
    17
    Par défaut Moyen efficace de valider une date de type dd/mm/yy puis de la stocker dans MySQL?
    Salut,

    Je précise que je travaille en environnement web (mod_perl), donc, le but pour moi n'est pas d'utiliser un module externe me permettant d'arriver à mes fins, mais qui consommerait beaucoup de mémoire, car diposant d'une multitue de fonctions inutiles pour moi.

    Voilà mon problème:
    Dans un formulaire HTML? j'ai un champ date. Je veux que l'utilisatur me retourne une date sous le format dd/mm/yyyy.
    JE voudrais pouvoir vérifier la validité de cette date (déja le format, mais ça, je peux le faire facilement avec une regexp) mais aussi si possible la validité (ex: ne pas avoir un 30/02/2006 ou un 31/04/2006).

    Le but est ensuite, si le format est valide, la stocker dans une table MySQL (donc, il me faudra sans doute faire une conversion par la suite pour l'insérer dans ma table)

    Puis je faire ça manuellement, ou me conseillez vous quand même l'utilisation d'un module externe? Si c'est le cas, lequel me conseillez vous? (j'insiste sur le fait que je ne souhaite pas avoir à charger un module ayant une empreinte mémoire trop grosse)

    Merci.

  2. #2
    Membre expert
    Avatar de 2Eurocents
    Profil pro
    Inscrit en
    septembre 2004
    Messages
    2 177
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 2 177
    Points : 3 161
    Points
    3 161
    Par défaut
    Pas besoin d'expression rationnelle si tu fais appel au module Date::Simple.

    En effet, celui ci gère aussi bien la validation (rejet des dates incorrectes) que le formattage (sortie au format "AAAA-MM-JJ" que l'on peut insérer sans soucis dans un champ DATE de MySQL).

    Il est parfait pour les usages simples, sans conversion de TimeZone et autres temps GMT ou UTC.


    Par contre, cela reste un module supplémentaire ... mais je ne suis pas sûr que son empreinte en mémoire soit SI importante ...

    Sinon, toujours avec des modules, mais en prenant ceux du "core" Perl, il doit y avoir moyen de s'en sortir avec Date::Parse et Date::Format.


    Sans module, il te faudra réinventer la roue
    La FAQ Perl est par ici
    : La fonction "Rechercher", on aurait dû la nommer "Retrouver" - essayez et vous verrez pourquoi !

  3. #3
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2004
    Messages
    79
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2004
    Messages : 79
    Points : 17
    Points
    17
    Par défaut
    Alors:

    D'une part, il ne me semble pas que Date:arse et Date::Simple fasse partie du core de Perl (enfin, y a aucune trace de ces deux modules sur le site de Perl, et mon ppm ne m'indique pas que je les ai).

    D'autre part, je pense que chacun de ces modules doit utiliser des regexp derrière les fagots.
    Finalement, je me dis que ma problématique est suffisamment smple pour que je puisse le faire moi même: ça me coûtera moins cher en terme de mémoire (sur un serveur web, si tu as 50 interprêteurs, ça peut devenir très lourd...)

    Je vais finalement m'en tirer en utilisant un truc du genre:

    my ($day, $month, $year) = ($str =~ /^(\d\d)\/(\d\d)\/(\d\d\d\d)$/);
    Par la suite, je vais tester que $day et $monthsont bien plus petits que 31/12 et plus grands que 0.

    Enfin, il se trouve que MySQL accepte des dates du type 31/02/2006 (enfin, sous la forme "2006/02/31", que ça ne le dérange pas que le jour n'existe pas, donc, ça me va très bien comme ça (je n'utilise cette date qu'à titre de comparaison avec d'autres).

    Cette expression régulière est vraiment simple, donc doit être rapide et utiliser peu de mémoire....

    Tu en penses quoi?

    Merci en tout cas.

  4. #4
    Membre expert
    Avatar de 2Eurocents
    Profil pro
    Inscrit en
    septembre 2004
    Messages
    2 177
    Détails du profil
    Informations personnelles :
    Âge : 49
    Localisation : France

    Informations forums :
    Inscription : septembre 2004
    Messages : 2 177
    Points : 3 161
    Points
    3 161
    Par défaut
    Tu as raison ... tous sont des modules CPAN ... J'ai tellement l'habitude de trouver Date::Parse et Date::Manip partout que je les ai cru dans le core.

    Citation Envoyé par Yoyo@
    D'autre part, je pense que chacun de ces modules doit utiliser des regexp derrière les fagots.
    Finalement, je me dis que ma problématique est suffisamment smple pour que je puisse le faire moi même: ça me coûtera moins cher en terme de mémoire (sur un serveur web, si tu as 50 interprêteurs, ça peut devenir très lourd...)
    ...
    Si je prends simplement la validation de date, je crois qu'il y a bien plus que de la simple vérification d'expression rationnelle (contrôle du 28/29 février, au hasard).

    Je me dis aussi que, par expérience, la consistance de mes données est, a toujours été, et restera pour longtemps encore ma préoccupation principale. Ainsi, si par un usage de modules éprouvés je peux garantir que mes données sont entrées de manière correcte et consistante dans mon SGBD, alors je suis prêt à assumer le surcoût opérationnel qui peut en découler.

    Je ne suis pas expert en mod_perl, mais 50 interpréteurs actifs en simultanés, ça peut être lourd, mais ça n'arrive que ponctuellement, non ? Et 1 Mo d'empreinte-mémoire supplémentaire par interpréteur, ça nous mène à 50 Mo, une valeur qui, pour être importante, n'en reste pas moins acceptable en régime transitoire, non ?

    L'important, pour moi, n'est pas le traitement, mais l'information qu'il manipule et produit.

    Maintenant, à toi de voir ce qui correspond le mieux à ton usage.
    La FAQ Perl est par ici
    : La fonction "Rechercher", on aurait dû la nommer "Retrouver" - essayez et vous verrez pourquoi !

  5. #5
    Membre à l'essai
    Profil pro
    Inscrit en
    août 2004
    Messages
    79
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : août 2004
    Messages : 79
    Points : 17
    Points
    17
    Par défaut
    Citation Envoyé par 2Eurocents
    Si je prends simplement la validation de date, je crois qu'il y a bien plus que de la simple vérification d'expression rationnelle (contrôle du 28/29 février, au hasard).
    Oui, sachant que ma date est tout ce qu'il y a de plus fixe, du type "dd/mm/yyyy", je pourrais me contenter de tester la longueur de la chaîne, puis de faire 3 subrstrings. Je ne sais pas si ce serait plus rapide que les regexp?
    Ici, je parle uniquement de contrôler le format d'entrée, et non pas de savoir si le 29/02 existe ou pas... (de toute façon, MySQL ne m'embêtera pas pour ça...)

    Citation Envoyé par 2Eurocents
    Je me dis aussi que, par expérience, la consistance de mes données est, a toujours été, et restera pour longtemps encore ma préoccupation principale. Ainsi, si par un usage de modules éprouvés je peux garantir que mes données sont entrées de manière correcte et consistante dans mon SGBD, alors je suis prêt à assumer le surcoût opérationnel qui peut en découler.
    Je suis 100% d'accord avec toi, mais ici, le test à effectuer est tellement simple que je n'ai aps trop à m'inquiéter, et il est facile d'avoir un contrôle fin de la chose...

    Citation Envoyé par 2Eurocents
    Je ne suis pas expert en mod_perl, mais 50 interpréteurs actifs en simultanés, ça peut être lourd, mais ça n'arrive que ponctuellement, non ? Et 1 Mo d'empreinte-mémoire supplémentaire par interpréteur, ça nous mène à 50 Mo, une valeur qui, pour être importante, n'en reste pas moins acceptable en régime transitoire, non ?
    Effectivement, vu sous cet angle là...
    Mais ce qu'il faut savoir c'est qu'une fois qu'un interprêteur Perl est mis en mémoire, il y reste. Donc, si je dimensionne mon serveur pour 50 accès simultanés au maximum, la trace mémoire correspondra à ces 50 interprêteurs (ce n'est qu'un exemple). D'autre part, une fois qu'un module est chargé en mémoire, il y reste également, et ce, dans l'espace mémoire de chaque interprêteur... Donc, il peut très vite y avoir un effet de boulimie... C'est pour ça que je souhaite utiliser les modules avec parcimonie (disons que je ne vais aps m'en priver, mais si je peux éviter de charger un gros module contenant des dizaines de fonctions, avec une implémentation maison facile, alors il faut que j'aille dans ce sens...

    En plus, sous Windows, il n'y a quasiment aucun partage de code: chaque interprpêteur dispose de sa propre version du code... (sous Linux, ça peut être différent, si tu utilise un système avec plusieurs processus)

    Merci pour ta réponse en tout cas.

    Et si tu as d'autres suggestions, elles sont les bienvenue.

Discussions similaires

  1. [RegEx] Valider une date
    Par m_biaggi dans le forum java.util
    Réponses: 5
    Dernier message: 16/02/2007, 12h30
  2. retourner une date de type different.
    Par Mobistar dans le forum Langage
    Réponses: 8
    Dernier message: 22/01/2007, 12h45
  3. Convertir une date en type string
    Par ziboux dans le forum SQL Procédural
    Réponses: 2
    Dernier message: 29/10/2003, 11h52

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo