Pourquoi est-il préférable de stocker un numéro de téléphone sous forme de chaîne par rapport à un entier?
Comme l'indique la question, pourquoi est-il considéré comme la meilleure pratique de stocker les numéros de téléphone sous forme de chaînes plutôt que d'entiers dans la colonne telephone_number?
Je ne suis pas sûr de comprendre la raison de cela. Aidez-nous à éclaircir ce point!
Merci!
Les numéros de téléphone sont des chaînes de caractères numériques, ce ne sont pas des entiers.
Considérez par exemple:
Exprimer un numéro de téléphone dans une base différente le rendrait insignifiant
Ajouter ou multiplier deux numéros de téléphone ensemble, ou toute opération mathématique sur un numéro de téléphone, n'a aucun sens. Le résultat n'est pas un autre numéro de téléphone (sauf par conicidence)
Les numéros de téléphone sont destinés à être entrés "tels quels" dans un appareil connecté.
Les numéros de téléphone peuvent comporter des zéros en tête.
Les manipulations de numéros de téléphone, telles que l'ajout d'un indicatif régional, sont des opérations String.
Le stockage de la version chaîne du numéro de téléphone rend cela clair et sans ambiguïté.
Historique: Sur les anciens systèmes de numérotation codés par impulsions, le code de chaque chiffre d'un numéro de téléphone était envoyé avec le même nombre d'impulsions que le chiffre (ou 10 impulsions pour "0"). C'est peut-être pourquoi nous utilisons toujours des chiffres pour représenter les parties d'un numéro de téléphone. Voir http://en.wikipedia.org/wiki/Pulse_dialing
Ce que Neil Slater a dit est correct. J'ajouterais qu'il existe de nombreux cas Edge où vous ne pouvez pas exprimer un numéro de téléphone en tant que valeur numérique de manière cohérente.
Par exemple, considérez ces chiffres:
011-123-555-1212
+11-123-555-1212
+1 (112) 355-5121 x2
Ce sont tous des numéros de téléphone potentiellement valides, mais ils signifient des choses très différentes. Pourtant, sous forme d'entier, ils sont tous 111235551212.
Si vous allez enregistrer le numéro à afficher depuis l'entrée, vous devez utiliser une chaîne.
Cependant, s'il est vrai qu'aucune opération mathématique ne peut être effectuée sur un nombre qui a un sens. L'utilisation d'un nombre dans des ensembles de hachage et pour l'indexation est plus rapide que l'utilisation d'une chaîne. Donc, à condition que vous puissiez garantir ou homogénéiser votre ensemble de nombres, de sorte qu'ils soient tous cohérents, vous pouvez voir de meilleures performances fonctionner sur un nombre.
Par exemple, dans le monde des télécommunications, l'évaluation des appels pour un client donné comprend beaucoup de recherches sur leur CLI et dans cette situation, il est plus rapide et moins cher de rechercher par entier. Généralement, bien que les chaînes soient de bonnes performances, ce n'est que là où les performances sont importantes et vous avez plusieurs recherches à effectuer pour une vaste gamme de nombres - c'est-à-dire évaluer 250 millions d'appels sur 2 millions de lignes et 2000 tarifs. En mémoire, le classement devient également coûteux, donc pouvoir utiliser un 64 bits int ou uint est moins cher lorsqu'il s'agit de ces volumes.
Considérez ces numéros de téléphone par exemple
099-1234-56789 ou +91-8907-687665.
Dans ce cas, si le phone_number l'attribut est de type integer, il ne peut donc pas accepter ces valeurs. Il devrait s'agir d'un string pour contenir ce type de valeurs. Donc string est toujours préférable à integer
Il y a plusieurs raisons à cela:
- Les numéros de téléphone commencent souvent par un "0": un entier supprimera tous les "0" en tête
- Le numéro de téléphone peut avoir un caractère spécial:
+,(,-, etc. (par exemple: +33 (0) 6 12 23 34) - Vous ne pouvez pas effectuer d'opérations sur les téléphones: l'ajout de téléphones, par exemple, n'aurait aucun sens
- Le numéro de téléphone peut être internationalisé, c'est-à-dire un format différent pour différentes personnes, donc impossible avec des entiers
Il pourrait y avoir d'autres raisons, mais je suppose que c'est déjà une bonne quantité de celles-ci :)