Type de données pour le numéro de téléphone: VARCHAR, INT ou BIGINT?
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:
Jetez un œil à la colonne from_number Qui est une VARCHAR(45) en 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 VARCHAR n'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 INT ou même BIGINT.
Lorsque je définis une colonne dans Workbench, je devrais spécifier le nombre entre parenthèses () Pas dans tous les cas mais dans ceux que je mentionne précédemment, je devais le faire. Donc, si je fais ceci: BIGINT() j'ai eu cette erreur:
Ce qui me guide pour lire un peu sur ce type MySQL ici . Fondamentalement, l'information est la suivante:
Un grand entier. ... La plage non signée va de 0 à 18446744073709551615.
Ce qui me fait me demander: quelle valeur je dois définir pour les parenthèses lorsque je définis un type BIGINT(). (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 la dernière édition de MySQL Workbench pour créer le diagramme ER. J'utilise aussi MariaDB 10.0.x
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 la colonne de votre numéro de téléphone. Si vous utilisez des numéroteurs automatisés à partir de cette colonne, vous voudrez 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.
Auparavant, il était écrit:
"Avec MariaDB, vous pouvez utiliser un champ computed 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 bases de données ont désormais introduit cette fonctionnalité. Ce sont des champs connus sous les noms de "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, il vous suffit de rechercher sur CAPs (en utilisant, par exemple, LIKE), sachant que les données recherchées dans le [computed | virtual | Le champ 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 . Quelques 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.
Je stocke généralement les numéros de téléphone dans 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 vraiment important.
Si votre entreprise souhaite effectuer appels sortants à partir de votre système, l'application extraira uniquement les numéros. Si votre entreprise souhaite effectuer appels internationaux, enregistrez l'indicatif de pays et l'indicatif régional dans des colonnes distinctes.
Si votre entreprise souhaite reporting, l'application formatera et affichera avec l'extension et les numéros séparément.
D'après ma compréhension, la conception 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. Aussi, j'ai appris, 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.
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 formatage 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 devrait ê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é.