Type de données pour le numéro de téléphone: VARCHAR, INT ou BIGINT?

12

Ce sera donc la question fictive de l'année mais je dois me poser car ce n'est pas la première fois que je passe par là. Jetez un œil à la définition de tableau suivante:

entrez la description de l'image ici

Jetez un oeil à la colonne from_numberqui est en VARCHAR(45)ce moment, mais elle contiendra un numéro de téléphone. Étant donné que je ne sais pas combien de numéros un téléphone pourrait avoir dans le monde, j'essaie de les couvrir presque tous. Je veux garder l'intégrité de la base de données autant que possible, donc je pense que ce VARCHARn'est pas un type approprié pour conserver ce type d'informations - peut-être que je me trompe, me dites-vous - alors je pense à changer pour INTou même BIGINT.

Lorsque je définis une colonne dans Workbench, je dois spécifier le nombre entre parenthèses ()non pas dans tous les cas, mais dans ceux que je mentionne précédemment, je devais le faire. Donc si je fais ça: BIGINT()j'ai cette erreur:

entrez la description de l'image ici

Ce qui me guide pour lire un peu sur ce type de MySQL ici . Fondamentalement, l'information est la suivante:

Un grand entier. ... La plage non signée va de 0 à 18446744073709551615.

Ce qui me fait demander: quelle valeur dois-je définir pour les parenthèses lorsque je définis un BIGINT()type. (J'utilise BIGINT parce que je ne sais pas si INT peut contenir autant de numéros qu'un téléphone pourrait avoir - peut-être que je me trompe aussi). Quelle est la bonne façon de créer | concevoir une colonne dans les bases de données MariaDB / MySQL?

Quoi qu'il en soit, je voudrais connaître votre opinion, votre expérience et bien sûr, je voudrais obtenir une réponse

Remarque: J'utilise MySQL Workbench dernière édition pour créer le diagramme ER. J'utilise aussi MariaDB 10.0.x

ReynierPM
la source

Réponses:

13

Comment géreriez-vous un numéro de téléphone avec une extension, comme "+ 1-000-000-0000 ext 1234"?

Notez que le "+" indique que les règles de numérotation internationales doivent être appliquées; donc depuis l'Amérique du Nord, le système connaît automatiquement "011" devant les appels internationaux, etc.

Et qu'en est-il des numéros de téléphone tels que "1-800-DBA-HELP"?

Je stocke généralement les numéros de téléphone sous forme de texte. Cela dit, cela dépend vraiment de l'importance de votre colonne de numéros de téléphone. Si vous utilisez des numéroteurs automatisés à partir de cette colonne, vous devez vraiment vous assurer que seuls les numéros sont inclus et que les données représentent des numéros de téléphone bien formés.

Vous pouvez avoir des colonnes distinctes pour les extensions et les numéros de téléphone contenant du texte, comme l'exemple "1-800-DBA-HELP" que j'ai fourni.

Max Vernon
la source
Oui, ils seront critiques, donc je ne ferai aucune erreur à l'avenir, sur la base que je n'autoriserais que les chiffres, quelle est votre suggestion? Est-il facile d'ajouter une nouvelle colonne contenant le numéro de poste ou je veux que les gens entrent des nombres comme 1-800-DBA-HELPpar ses chiffres
ReynierPM
Cela dépend vraiment de vos besoins. Si vous devez conserver la reconnaissance humaine, je voudrais certainement conserver les numéros basés sur du texte quelque part, probablement dans un champ de texte. Si vous ne vous souciez pas de la partie texte, ne les stockez pas.
Max Vernon
1
L'INT n'est certainement pas assez grand si vous stockez le numéro complet avec le code du pays. BIGINT est probablement assez grand.
Max Vernon
1
Je voudrais au moins 20 chiffres.
Max Vernon
1
Avec MariaDB, vous pouvez utiliser un champ calculé pour extraire uniquement les chiffres d'un numéroteur automatique. Peut-être dans MySQL 5.7 (pas sûr).
Vérace
2

Auparavant, il était écrit:

"Avec MariaDB, vous pouvez utiliser un computedchamp pour extraire uniquement les chiffres d'un numéroteur automatique. Fonctionne également pour MySQL 5.7."

En réponse à la question du PO à ce sujet ("pouvez-vous expliquer un peu ce que vous me dites?"), Voici une explication.

De nombreux systèmes de base de données ont désormais introduit cette fonctionnalité. Ce sont des champs qui sont appelés diversement " computed", " virtual" ou " generated" qui sont dérivés de valeurs dans d'autres champs. La puissance de cette fonction variera en fonction de votre SGBDR. Je sais qu'Oracle, Firebird, MariaDB et maintenant MySQL 5.7 en ont. D'autres le font probablement aussi.

Un exemple simple serait d'avoir une colonne de nom de famille et d'avoir une colonne calculée qui "stocke" (rappelez-vous, ils peuvent être virtuels - c.-à-d. Calculés à la volée, ou ils peuvent être physiquement stockés sur le disque) le nom de famille comme toutes les capitales, faisant ainsi recherche plus facile. De cette façon, vous n'avez qu'à rechercher sur CAPs (en utilisant, disons LIKE), sachant que les données recherchées dans le [ computed| virtual| generated] est en texte majuscule.

Le concept de MySQL 5.7 est expliqué ici et ici . Il est dans MariaDB depuis un peu plus longtemps et le concept est également expliqué ici . Certaines utilisations possibles sont suggérées ici , mais vous n'êtes vraiment limité que par votre imagination. Ils peuvent être considérés comme un substitut pratique (et moins sujet aux erreurs) des déclencheurs.

Pour votre cas d'utilisation particulier, vous pouvez dériver un numéro composable à partir d'un champ de texte "+" -> "00" (ou quel que soit votre code de numérotation international). Juste une pensée.

Vérace
la source
Très bien, pouvez-vous améliorer un peu votre question en ajoutant des requêtes? Je veux dire que j'ai compris le concept, mais je ne sais pas comment créer les valeurs virtualou generated. Je pense à l'utilisation CONCATou à autre chose, mais je n'en suis pas sûr du tout. Vous mentionnez également une recherche en CAPSutilisant LIKEpourriez-vous en mettre un exemple également? Qu'en est-il des performances des colonnes calculées à la volée ( virtual) vs persisted (générées)?
ReynierPM
1

Hmm. Les numéros de téléphone sont composés de chiffres. L'utilisation de varchar permet à l'utilisateur de stocker tout type de mise en forme, avec (ou non, avec - ou. Et cela crée rapidement un gâchis avec vos données. Un format de téléphone # dépend du pays, le masque doit être lié au pays. Extension est une extension et est facultative, donc elle doit être stockée dans un "champ d'extension". (int aussi). Pour 1-800-DBA-HELP, je convertirais cela à la volée et enregistrerais le nombre réel. Si vous en avez vraiment besoin numéro de téléphone lisible par l'homme, stockez-le dans un champ varchar séparé.

greenlitmysql
la source
1

Je stocke généralement les numéros de téléphone dans un texte simple . Le formatage et l'affichage le laissent au code client.

Ici, plus que comment vous stockez? ce que vous allez faire avec ce numéro de téléphone est très important.

Si votre entreprise souhaite effectuer des appels sortants à partir de votre système, l'application extraira uniquement les numéros. Si votre entreprise souhaite effectuer des appels internationaux , enregistrez l'indicatif de pays et l'indicatif régional dans des colonnes distinctes.

Si votre entreprise souhaite des rapports , l'application formatera et affichera avec l'extension et les numéros séparément.

D'après ma compréhension, la conception d' un modèle de données universel pour le numéro de téléphone n'est pas une bonne idée. Chaque pays a des numéros, des extensions et un indicatif régional différents du code de pays. De plus, j'ai appris que certains pays n'ont pas d'indicatif régional.

Cela ne répondra peut-être pas à votre question, mais cela contribuera à élargir notre compréhension. Je vous remercie.

rathishDBA
la source