Forum Programmation.autre Requête SQL avancée

Posté par  .
Étiquettes : aucune
0
24
juil.
2004
Bonjour à tous,

je souhaites traiter des chaînes de caractères directement dans la requête SQL.

J'ai deux champs : nom et prénom.

Exemple :
NOM | PRENOM
Dupont | Jacques
De Compègne | Pierre
De l'Huîre | Paul

Je voudrais que ma requête me renvoie directement une chaîne de caractères un peu plus 'système'.

En résumé :
  • il faut remplacer les accents par la lettre normal (é=>e...),
  • remplacer les apostrophe et les espace par le caractère souligné,
  • tout mettre en minuscule,
  • etc...


    Ce qui donnerai
    IDENTIFIANT
    jacques_dupont
    pierre_de_compegne
    paul_de_l_huire

    Existe t'il une solution à ce type de problème ou suis je condamné à traiter ce problème coté client ?

    Merci.

  • # de toute façon ...

    Posté par  . Évalué à 0.

    "traiter ce problème coté client ?"

    c'est pas le client qui fait la requête ?

    Sinon typiquement ça, c'est pas dans le protocole SQL standard, donc il faudrait préciser avec quel sgbd tu veux faire ça, pour savoir si il fait ce genre de truc. M'est avis que tu ne trouveras pas grand chose, et puis de toute façon, si tu veux que ton truc soit indépendant du serveur sgbd qui est derrière, t'as pas trop le choix, je dirai que tu dois te le farcir à la main ...

    deux ou trois regexp devraient régler très rapidement le problème.

  • # C'est pas compliqué !

    Posté par  . Évalué à 1.

    Bonjour à toi seulement.

    Ce que je ferais dans ton cas, c'est d'abord un fonction sur le serveur/sgbd, et ensuite appeler cette fonction dans une requête ou à travers une vue.
    Cela dit, tu aurais pu préciser au moins le SGBD employé (divers languages sont possibles pour certains). J'ai déjà fait des fonctions sql et plpgsql avec PostgreSQL par exemple ...

    Tu fais donc un truc du style :
    CREATE FUNCTION format_identifiant( TEXT, TEXT ) RETURNS TEXT AS ...;
    puis
    SELECT format_identifiant( nom, prenom) as identifiant FROM table ...;

    Mon conseil, c'est d'éviter de faire les remplacements au niveau du client : si tu changes de language, tu dois tout refaire tout sinon !

    • [^] # Re: C'est pas compliqué !

      Posté par  . Évalué à 2.

      Merci pour la piste que tu me donne.

      Le serveur qui héberge le site utilise MySQL.

      Puisque apparement il faut un binaire pour faire ça, je vais négocier avec l'hébergeur pour voir si il accepterait.

      • [^] # Re: C'est pas compliqué !

        Posté par  . Évalué à 1.

        Pourquoi tu me causes de binaire ?
        Parce qu'il faut une 'extension' pour gérer des fonctions côté serveur ? alors qu'à mon sens ça devrait faire partie de la base !

        Ce n'e sont que des questions innocentes ! Pour ma part, je n'utilise que sur mon propre réseau local ... l'admin est moins vache ;-)

        • [^] # Re: C'est pas compliqué !

          Posté par  . Évalué à 1.

          ooops !

          Après quelques recherches, il me semble que MySQL ne gère les procédures stockées qu'à partir de la version 5.0 ... qui n'est pas encore finalisée. Quid de sont adoption rapide par les hébergeur à sa sortie ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.