Contrainte téléphone varchar

[nitch01]

* Bonjour, *

J'ai un champ nommé "Téléphone"de type varchar
et je dois ajouter une contrainte au quelle le numéro de téléphone doit être composer de 10 chiffres de (0 à 9)
pourriez vous m'aidez s'il vous plait

[CinePhil]

Quel est ton SGBD ?

[nitch01]

SQL SERVER 2005

[zinzineti]

Envoyé par nitch01

J'ai un champ nommé "Téléphone"de type varchar
et je dois ajouter une contrainte au quelle le numéro de téléphone doit être composer de 10 chiffres de (0 à 9)
pourriez vous m'aidez s'il vous plait

Il faut d'abord bien se renseigner sur ce que tu veux stocker. Si j'ai bien compris il s'agit de stocker un numéro de téléphone.

Un numéro de téléphone peut être composé de 2, 3, 4 jusqu'à 13 chiffres.

Si tu es CERTAIN qu'à chaque fois tu attend un numéro à 10 chiffres alors tu peux :

1.) Changer le type VARCHAR de la colonne Telephone en CHAR (10)

2.) Poser la contrainte

Code :

1
2
3
4
Telephone CHAR(10) NULL
              CONSTRAINT ck_phone 
                    CHECK(Telephone 
                         LIKE ('[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'))

Mais encore une fois renseigne-toi bien, à ta place je vais tailler la colonne Telephone sur 13 caractères et j'aurai donc quelque chose qui ressemble à :

Code :

1
2
3
4
Telephone CHAR(13) NULL
              CONSTRAINT ck_phone 
                    CHECK(Telephone 
                         LIKE ('[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]') OR Telephone LIKE ('[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]'))

A+

[zinzineti]

Question :
Est ce que le numéro de téléphone que vous désirez stocker peut contenir des caractères : espaces ' ', tirets '-' , point '.' ?

A+

[Sergejack]

Sql Server n'offre pas la souplesse des expressions régulières et les limites du lie sont très contraignantes.
Je vous conseille donc de ne pas tenter de placer cette règle du côté Sql Server.

[mikedavem]

Il est possible à partir de la version 2005 d'utiliser CLR et les RegExp pour pallier ce défaut (et si votre besoin s'en fait vraiment ressentir).

Ne pas placer cette contrainte côté SQL Server me parait dangereux en plus ...

++

[zinzineti]

Un exemple ici

http://msdn.microsoft.com/fr-fr/magazine/cc163473.aspx

[SQLpro]

Code :

1
2
3
ALTER TABLE MaTAble 
   ADD CONSTRAINT CK_TEL 
      CHECK(MaColonneTel LIKE '[0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]')

Contrairement à ce qui vous a été affirmé, il est conseillé d'utiliser un type de données chaine de caractères pour les téléphone comme pour les codes postaux, n° de compte en banque, etc. En effet rien n'indique à l'avenir que ces données ne soient pas un jour sujette à stocker des lettres, comme ce fut le cas des n° de téléphone dans le passé ! La règle en la matière étant :
- si la données doit être sujette à des calculs, alors prendre un type numérique
- dans le cas contraire, prendre le type le plus "large" c'est à dire celui qui accepte tous les symboles possibles !

A +

[zinzineti]

Envoyé par SQLpro

Contrairement à ce qui vous a été affirmé, il est conseillé d'utiliser un type de données chaine de caractères pour les téléphone comme pour les codes postaux, n° de compte en banque, etc.

Chaîne de caractères, oui mais char ou varchar ?

Envoyé par SQLpro

En effet rien n'indique à l'avenir que ces données ne soient pas un jour sujette à stocker des lettres, comme ce fut le cas des n° de téléphone dans le passé ! La règle en la matière étant :
- si la données doit être sujette à des calculs, alors prendre un type numérique
- dans le cas contraire, prendre le type le plus "large" c'est à dire celui qui accepte tous les symboles possibles !

Dans la pratique c'est ce qu'on constate.
Imaginez chez un même éditeur de solutions de centre d'appel on voit la colonne Telephone tantôt taillée sur VARCHAR (40) tantôt sur VARCHAR (50)

Chez un autre éditeur la colonne Telephone est taillée sur :
VARCHAR (255)

Un troisième éditeur toujours dans le même domaine de centre d'appel choisit pour la colonne Telephone :
nvarchar (20)

C'est ce désordre qui ne me plaît pas !

Car il existe aujourd'hui des normes internationales émises par l’Union internationale des télécommunications (principalement les recommandations UIT-T E.122, E.123 et E.126)

Et il suffit simplement de respecter ces recommandations ou si on veut tailler large de prendre le plus grand nombre possible de caractères que peut avoir un numéro de téléphone aujourd'hui.

Une règle simple doit nous guider à choisir le type de colonne : éviter le gaspillage (mémoire et disque) !

Vu la multiplication des numéros de téléphones (moi personnellement j'en ai 1 fixe et 2 GSM) on peut imaginer que les chiffres seuls ne suffisent plus en qu'on peut être amener à intégrer des lettres dans les "numéros" de téléphone

du coup la colonne Telephone initialement bien taillée doit subir une modification pour accepter les nouvelles valeurs de téléphones.

Et à mon avis un ALTER TABLE ALTER COLUMN devrait suffir pour remettre tout en ordre :

Code :

1
2
ALTER TABLE myTable
 ALTER COLUMN Telephone nouveauType (NouvelleValeur);

Une dernière question pour finir (je connais la réponse) :

Quel est aujourd’hui le nombre de caractères maximales pour un numéro de téléphone dans le monde (sans les espaces, les points, les tirets) ?


A propos de la convention de l'union européenne pour les numéros de téléphones

[elsuket]

Bonjour,

Pour avoir travaillé avec des numéros de téléphone provenant de plusieurs pays dont l'entreprise dans laquelle je travaillais dépendait littéralement, c'est 15 digits.
J'ai donc stocké tout ça dans une colonne de type varchar(20) au cas où.

Supposons que j'aie choisi de stocker ces valeurs en varchar(15).
Cela n'aurait rien changé au comportement de l'application et de la base de données, puisque toute valeur de type varchar, quelle que soit la longueur que l'on s'impose, implique l'utilisation de deux octets supplémentaire qui permettent d'indiquer la fin de chaîne.

Pour moi le problème se situe plutôt dans l'indexation, lorsqu'on doit retrouver un client à partir de son numéro de téléphone qui est souvent la seule information dont on dispose ...
Je me suis donc tourné vers la fonction HASHBYTES() qui retourne un varbinary.
Je l'ai mise en colonne calculée persistante indexée, et cela a très bien fonctionné.

@++

[zinzineti]

Envoyé par elsuket

Bonjour,
Pour avoir travaillé avec des numéros de téléphone provenant de plusieurs pays dont l'entreprise dans laquelle je travaillais dépendait littéralement, c'est 15 digits.

Bien

Envoyé par elsuket

J'ai donc stocké tout ça dans une colonne de type varchar(20) au cas où.

Pourquoi au cas où ? au cas où quoi ?
s'il s'agit de stocker par exemple des noms je peux comprendre le "au cas où ?"

Envoyé par elsuket

Supposons que j'aie choisi de stocker ces valeurs en varchar(15).
Cela n'aurait rien changé au comportement de l'application et de la base de données, puisque toute valeur de type varchar, quelle que soit la longueur que l'on s'impose, implique l'utilisation de deux octets supplémentaire qui permettent d'indiquer la fin de chaîne.

Je suis d'accord.

Envoyé par elsuket

Pour moi le problème se situe plutôt dans l'indexation, lorsqu'on doit retrouver un client à partir de son numéro de téléphone qui est souvent la seule information dont on dispose ...
Je me suis donc tourné vers la fonction HASHBYTES() qui retourne un varbinary.
Je l'ai mise en colonne calculée persistante indexée, et cela a très bien fonctionné.
@++

Effectivement si on a une idée vague de ce qu'on veut stocker on peut être large sur la largueur des colonnes mais ce n'est pas le cas pour un numéro de téléphone.
Par contre sur les IHM, il faut prévoir toutes les fantaisies ... ceux qui préfèrent mettre des espaces, des points, des tirets entre les chiffres.
Ce qui demande un traitement préalable avant le stockage dans la base. Et ce n'est pas si simple


A+

[elsuket]

Envoyé par zinzinetti

s'il s'agit de stocker par exemple des noms je peux comprendre le "au cas où ? "

En fait je disais cela au cas où notre entreprise aurait eu l'opportunité de s'ouvrir à un nouveau pays (originellement nous travaillions en Thaïlande, Indonésie, Australie et Afrique du Sud), et/ou que la numérotation serait venue à changer.

Pour l'anecdote, les numéros en Indonésie étaient gérés d'une façon assez anarchique (cela a peut-être changé depuis), si bien que nous avions des numéros dont la taille allait de 8 à 12 chiffres pour ce pays ...

@++

[zinzineti]

Je comprends

La chose n'est pas si simple même au sein d'une entreprise dans un même pays :

Numéro interne, Numéro Externe, Numéro SDA, ...

Il faut bien se renseigner sur ce que les gens veulent stocker.

C'est ce que je suggérais à "nitch01" qui veut poser des contraintes sur une colonne Telephone.

Je pense qu'au travers de cette discussion il a trouvé son "bonheur" ?

A +

[elsuket]

Je viens de découvrir ici qu'il n'y a aucun indicatif téléphonique commençant par zéro.

Cela signifie directement que l'on peut stocker les numéros de téléphone sous le type BIGINT (donc sans le "+", et en supposant qu'il n'y aura jamais de lettre dans les numéros de téléphone).

On peut ensuite créer une contrainte de domaine (CHECK) supportée par une fonction scalaire, qui vérifie le format du numéro à l'aide d'une table les spécifiant.

@++

[zinzineti]

Envoyé par elsuket

Je viens de découvrir ici qu'il n'y a aucun indicatif téléphonique commençant par zéro.

les indicatifs comment toujours par 00 ou par +
là ils se sont gourés !
Je suppose qu'ils ont fait leur saisie dans Excel qui a viré tous les zéros qui sont devant les chiffres

J'ai fais un test rapide avec mon téléphone en composant :

336XXXXXXXX et je reçois le message du genre : "..... le numéro demandé n'est pas attribué "
alors que le
+336XXXXXXXX ou le 00336XXXXXXXX marchent bien.

Il faut modifier/signaler cette erreur sur la page Wiki.


A+