Rajouter des espace dans les numéros de téléphones [Résolu]

[zooffy]

Bonjour

Je suis devant une idée, mais je ne sais vraiment pas par quelle bout la prendre.

Dans ma base de donnée, je stocke des numéros de téléphone sur 10 caractère en VARCHAR(10). Le client voudrais qu'à l'affichage il y ait des espace tous les deux chiffre dans le numéros de téléphone. Sauf que le stockage, pour des raisons technique sur le restatn du programme doit rester sans espace.

Donc, je suis dit que j'alais bricoler une mise en forme dans les requêtes.
Alors là, je suis en train de tenter un découpage de la chaine avec une insertion d'espace, mais ça ma parait fastidieu.

Alors je vers vous pour savoir si vous n'avez pas une solution plus facile à mettre en place.

Merci pour votre aide.

[rudib]

Bonjour,

Il vaut mieux le faire en expression rationnelle dans le langage client. Sinon :

Code :

SELECT STUFF(STUFF('1234567890', 3, 0, ' '), 6, 0, ' ')

et ainsi de suite.

[zooffy]

Merci, c'est pile poil ce que je cherchais.
Je connaissais pas cette instruction STUFF

Je te l'accorde, ça serait mieux de la faire dans la langage client.
Mais je me trouve devant un choix pas si corniellien que ça :
modifier une 15 zaine de requête apr un simple copier coller d'une ligne à la place d'une autre
ou
modifier 120 pages ASP, avec du code dans tous les sens (et oui, ASP 3.0 c'est du script et ça fait mal à l'heure de .NET d'être encore obligé de développer avec ça, mais bon, la patronne, c'est la patronne ........) et en plus prendre des vrais risque d'effet de bords, plus rajouter des procédure pour gérer l'insertion des donéne, donc faire des masque de saisie pour être sûr que les secrétaire à l'autre bout, vont pas se gauler.

Déjà que ça a été compliqué des les faire saisir sans les espaces, alors si je les perturbe encore, ben je vais pas me faire des copinnes. Tu sais aussi bien que moi que la secrétaire est un anmial bizarre qui aime bien ses habitude et surtout ne supporte pas d'en changer, voir même considère le changement comme un danger beaucoup plus grave que la bombe atomique, le sida et et le réchauffement climatique cumulé !

hum, hum, pardon, je mégare, mais bon, bonne humeur ce matin, super week-end ensolleillé avec mon nouvel amour, bref que du bonheur que j'ai envie de partager.

ALors merci à toi pour ce STUFF salvateur.

Kenavo

[rudib]

Pas besoin de copier-coller : crées une fonction utilistaeur (UDF) avec ce code.

[rudib]

... et j'en déduis que ton nouvel amour n'est pas une secrétaire.

[cavo789]

Un problème auquel j'ai souvent été confronté : comment fais-tu pour savoir où mettre des espaces et comment faire les regroupements ?

Je m'explique : en fonction du pays et/ou de la région, le layout est différent.

Pour la Belgique, voici un numéro de téléphone à Bruxelles

+32 02 218 98 65

Et voici, toujours pour la Belgique, un numéro de téléphone pour la ville de Mons.

+32 065 02 03 06

Et pour les numéros de mobiles, c'est encore une autre histoire d'où le problème : comment développer une udf capable d'afficher correctement le numéro de téléphone de manière standardisée. Je n'ai jamais vraiment trouvé; j'ai toujours du chipoter.

[rudib]

Pas vraiment possible en SQL. Il vaut mieux déployer une belle expression rationnelle dans un langage qui le supporte. Au pire, une UDF en .NET, mais c'est à éviter pour des raisons de performances.

[zooffy]

Envoyé par cavo789

Un problème auquel j'ai souvent été confronté :
[...]
numéro de téléphone de manière standardisée. Je n'ai jamais vraiment trouvé; j'ai toujours du chipoter.

Mais non, vas mon pote, chipote ! !
En fait c'est trop cool de chipoter.

Sinon, même si je suis pas toujours ua top avec le langage SQL, je reste un bon ingénieur, enfin, c'est pas moi qui el dit.
Donc, perso, je ne suis pas confronté à ce problème parce que le site que je programme est prévu pour ne fonctionner que en France, donc sur 10 chiffre pour tous les numéros de téléphone.

Mais, si on veut faire les choses bien, il faut utiliser uniquement le format international sur 13 plots. Du coup, une fonction devient parfaitement possible. Mais je vais contre dire ce point juste aprés.

Envoyé par rudib

... et j'en déduis que ton nouvel amour n'est pas une secrétaire.

Non, elle est maquilleuse évènementiel et artiste peintre. Elle a un talent fou et pas que pous ça...............................................
Mais peut être que je ne suis pas objectif, en fait......

Envoyé par rudib

Pas besoin de copier-coller : crées une fonction utilistaeur (UDF) avec ce code.

Alors là, j'en suis revenu. Certes, les fonctions c'est super cool. Mais je me suis aperçu qu'a l'usage, ça plombe les performances.
Maintenant, peut-être que je les utilise mal. J'étais parti sur le fait de faire des fonction pour faire des présentations de données, genre mettre en forme les date, les sommes avec des Euros, des recherches de client avec des infos (adresse, télé, nom, prénom, civilité,...) voir même prendre l premeir client de la liste sur un même bien pour n'afficher que celui là et pas les autres.

Mais, vu le nombre de champ que je dois remonter sur certaine page et le nombre de bien dans la base, ben les perf sont à genoux et je suis revenu aux bonnes vielles jointures.

Mais je pense que j'ai loupé un truc dans l'utilisation des fonctions. Faudrait que je reparte en cours. Je verrais ça quand je serais au chômage, le mois prochain.

Kenavo

[cavo789]

Envoyé par zooffy

faire des fonction pour faire des présentations de données, genre mettre en forme les date, les sommes avec des Euros

J'entends déjà SQLPro crier au fou... en arguant à raison que ce n'est pas le rôle du SGBD de faire de la mise en forme mais bien à l'application client.

A priori, SQL Server n'a pas à se soucier des settings internationaux de ton client client, si l'affichage se fait en euro ou en dollar, que le format de date soit européen ou anglais ou autre; SQL Server doesn't care. Par exemple, c'est SSRS qui devrait s'en soucier en utilisant le paramètre Language du rapport.

[rudib]

Envoyé par zooffy

Alors là, j'en suis revenu. Certes, les fonctions c'est super cool. Mais je me suis aperçu qu'a l'usage, ça plombe les performances.

les UDF sont très pénalisantes quand elles charchent dans une autre table, mais pour des utilisations cosmétiques de ce genre, la perte de perf est limitée.

[zooffy]

Envoyé par rudib

les UDF sont très pénalisantes quand elles charchent dans une autre table, mais pour des utilisations cosmétiques de ce genre, la perte de perf est limitée.

Ouaip, peut être, mais même pour la cosméto, j'ai fait un gros retour vers les Jointures.
Disons que je me repencherais sur la question ultérieurement, pour bien maitriser les principes d'utilsation des fonctions et aussi penser un peu plus optimisation de la BDD.

Envoyé par cavo789

J'entends déjà SQLPro crier au fou...
[...]
SQL Server doesn't care.

Tu vas voir si SQL y va "doesn't care" comme ça (et en plus m'en fout parce que j'entrave rien à l'anglais......)
Et pis SQLPro, ben y peut braire autan qu'il veut, m'en fout, j'ai l'habitude des concerts de Métal, ça m'étonnerait qu'il envoi autant de Decibel que Rammstein à Bercy ! ! !

Mais non SQLPro, fait pas la tête, c'était pour rire que je disais ça ......
Heu ben oui, parce que il m'a assez souvent sorti de la mouise pour que je me doivent un minimum de respect à son égard : c'est un

Bon, soyons sérieux deux minutes : sur le fait de dire que c'est le langage client qui doit le faire, oui , je suis d'accord sur le principe, sauf que :
- actuellement, dans le domaine du Web (je ne parle que de ce que je connais vraiment) on assiste à une configuration trés répandue : un serveur pour le frontal et un serveur pour la BDD
- SQL server est une grosse faignasse qu'on ne fait pas assez travailler
- je trouve un poil plus simple de rajouter des petites chose comme + '<br>' dans le SELECT de la requête, plutôt que de ce goinfrer des mises en forme une fois arrivé dans la page. Ou d'agréger directemtn dans le SELECT les différent champ qu is'afficheront sur une ligne, genre : SELECT Nom + ' ' + Prenom + ' ' + Ville AS EtatCivil FROM LaTable
- sur les formats, je ne parlais pas des internationnaux ou truc du genre, mais plutôt un bidule maison, genre le client veut un espace tous les chiffres dans les nombres ou il veut les dates avec les années sur trois chiffres (oui, je sais, cet exemple un peu capilotracté)

Bref, je suis d'accord sur le principe, mais selon l'usage, ben parfois c'est mieux autrement. Le jour où je travaille avec une plateforme d'hébergement digne de ce nom (euh, oui, ici , c'est une vraie merde, mais c'est pas moi le boss, alors...) par exemple si je me retrouve avec une plate forme en load balancing, donc avec le SQL sur le même serveur sur le IIS, là oui, je change ma façon de programmer et je décharge au maximum SQL de fonctions subalternes que je coderais mieux en VB (par exemple).
Mais bon, faut pas réver, le jour où je pourrais bosser sur une palte forme pareille n'est pas arrivé, c'est un rêve, une chimère voir même un phantasme.....

Ah, que l'informatique est belle, qu'elle grande, qu'elle nous apporte notre bonheur quotidien et assouvisse nos désirs les plus fous.

Bonne journée les copains.