Quel type de données faut-il utiliser pour stocker les numéros de téléphone dans SQL Server 2005?

Question

Je dois stocker les numéros de téléphone dans un tableau. Veuillez suggérer quel type de données dois-je utiliser? Attendez. Veuillez lire avant de répondre ..

Ce champ doit être fortement indexé car les commerciaux peuvent utiliser ce champ pour la recherche (y compris la recherche de caractères génériques).

Pour l'instant, nous nous attendons à ce que les numéros de téléphone se présentent sous différents formats (à partir d'un fichier XML). Dois-je écrire un analyseur syntaxique pour convertir en un format uniforme? Il pourrait y avoir des millions de données (avec des doublons) et je ne veux pas gêner les ressources du serveur (dans des activités telles que le prétraitement excessif) à chaque fois que des données source arrivent.

Toutes les suggestions sont les bienvenues.

Mise à jour: Je n'ai aucun contrôle sur les données source. Juste que la structure du fichier XML est standard. Voudrais garder l'analyse xml au minimum. Une fois dans la base de données, la récupération devrait être rapide. Une suggestion insensée est que cela devrait même fonctionner avec la fonctionnalité de saisie semi-automatique Ajax (afin que les commerciaux puissent voir immédiatement ceux qui correspondent). OMG !!

Answer 1

Est-ce que cela inclut:

• Numéros internationaux?
• Extensions?
• D'autres informations que le nombre réel (comme "demander pour un bobby")?

Si ce n’est pas le cas, j’utiliserais un champ de 10 caractères pour supprimer toutes les données non numériques. Si le premier est un oui et les deux autres sont un non, j'utiliserais deux champs varchar (50), un pour l'entrée d'origine et un avec toutes les données non numériques agrégées par bande et utilisées pour l'indexation. Si 2 ou 3 sont oui, je pense que je ferais deux champs et une sorte d'analyseur syntaxique fou pour déterminer ce que sont des données d'extension ou autres et les traiter de manière appropriée. Bien sûr, vous pouvez éviter la 2ème colonne en faisant quelque chose avec l'index qui supprime les caractères supplémentaires lors de la création de l'index, mais je créerais simplement une seconde colonne et supprimerais probablement les caractères avec un déclencheur.

Mise à jour: pour résoudre le problème AJAX, il se peut que ce ne soit pas aussi grave que vous le pensez. Si c’est de manière réaliste le moyen principal de traiter la table, ne stockez que les chiffres dans une colonne secondaire, comme je l’ai dit, puis définissez l’index de cette colonne en cluster.

Answer 2

Nous utilisons varchar (15) et indexons certainement sur ce champ.

La raison en est que les normes internationales peuvent prendre en charge jusqu'à 15 chiffres

Wikipedia - Formats de numéros de téléphone

Si vous prenez en charge les numéros internationaux, je vous recommande de stocker séparément un code de zone mondiale ou un code de pays afin de mieux filtrer les requêtes afin de ne pas vous retrouver à analyser et à vérifier la longueur de vos champs de numéro de téléphone afin de limiter les appels renvoyés. aux USA par exemple

Answer 3

Utilisez CHAR (10) si vous ne stockez que des numéros de téléphone américains. Supprimez tout sauf les chiffres.

Answer 4

Il me manque probablement une évidence, mais un varchar ne serait-il pas suffisant pour que votre numéro de téléphone attendu le plus long fonctionne correctement?

Si il me manque quelque chose d'évident, j'aimerais que quelqu'un le fasse remarquer ...

Answer 5

Je voudrais utiliser un varchar (22). Assez grand pour contenir un numéro de téléphone nord-américain avec extension. Vous voudriez éliminer tous les méchants caractères '(', ')', '-' ou simplement les analyser dans un format uniforme.

Alex

Answer 6

SQL Server 2005 est plutôt bien optimisé pour les requêtes de sous-chaîne pour le texte dans les champs varchar indexés. Pour 2005, ils ont introduit de nouvelles statistiques dans le résumé de chaîne pour les champs d'index. Cela aide considérablement à la recherche en texte intégral.

Answer 7

utiliser varchar est plutôt inefficace. utilisez le type d'argent et créez un type déclaré par l'utilisateur "numéro de téléphone". et créez une règle pour autoriser uniquement les nombres positifs.

si vous le déclarez comme (19,4), vous pouvez même stocker une extension à 4 chiffres et être assez grand pour les numéros internationaux, et ne prend que 9 octets de stockage. De plus, les index sont rapides.

Answer 8

nvarchar avec prétraitement pour les normaliser autant que possible. Vous voudrez probablement extraire des extensions et les stocker dans un autre champ.

Answer 9

Normalisez les données puis stockez-les en tant que varchar. La normalisation pourrait être délicate.

Cela devrait être un succès ponctuel. Puis, lorsqu'un nouvel enregistrement arrive, vous le comparez à des données normalisées. Devrait être très rapide.

Answer 10

Etant donné que vous devez accepter de nombreux formats de numéros de téléphone différents (et probablement inclure des éléments tels que des extensions, etc.), il peut être plus logique de le traiter comme vous le feriez de tout autre varchar. Si vous pouviez contrôler l'entrée, vous pourriez adopter plusieurs approches pour rendre les données plus utiles, mais cela ne sonne pas comme ça.

Une fois que vous décidez simplement de la traiter comme une autre chaîne, vous pouvez vous concentrer sur les problèmes inévitables liés aux mauvaises données, à la mise en forme de numéros de téléphone mystérieux et à tout ce qui va apparaître. Le défi consistera à élaborer une bonne stratégie de recherche pour les données et non pas comment vous les stockez à mon avis. Il est toujours difficile de gérer une pile de données importante sur laquelle vous n’ayez aucun contrôle sur la collecte.

Answer 11

Utilisez SSIS pour extraire et traiter les informations. De cette façon, le traitement des fichiers XML sera séparé de SQL Server. Vous pouvez également effectuer les transformations SSIS sur un serveur distinct si nécessaire. Enregistrez les numéros de téléphone dans un format standard à l'aide de VARCHAR. NVARCHAR serait inutile puisque nous parlons de chiffres et peut-être de deux autres caractères, comme '+', '', '(', ')' et '-'.

Answer 12

Utilisez un champ varchar avec une restriction de longueur.

Answer 13

Il est assez courant d’utiliser un & x; x " ou " ext " pour indiquer des extensions, prévoyez donc 15 caractères (pour le support international complet) plus 3 (pour "ext") plus 4 (pour l'extension elle-même), soit un total de 22 caractères. Cela devrait vous garder en sécurité.

Vous pouvez également normaliser les entrées de manière à ce que les options " ext " est traduit en "x", donnant un maximum de 20.

Answer 14

Je réalise que ce fil est ancien, mais il convient de mentionner un avantage de stocker sous forme de type numérique à des fins de formatage, en particulier dans le framework .NET.

IE

.DefaultCellStyle.Format = "(###)###-####" // Will not work on a string

Answer 15

Il est toujours préférable de disposer de tableaux distincts pour les attributs à valeurs multiples tels que le numéro de téléphone.

Comme vous n’avez aucun contrôle sur les données source, vous pouvez analyser les données à partir d’un fichier XML et les convertir au format approprié pour éviter tout problème lié aux formats d’un pays donné et les stocker dans un tableau séparé. que l'indexation et la récupération soient efficaces .

Merci.