type de données mysql pour le numéro de téléphone et l'adresse
je veux de saisie de numéro de téléphone dans un formulaire, y compris le code du pays, l'extension
create table if not exists employee( `
country_code_tel int(11),
tel_number int(10),
extension int(10),
mobile bigint(20)
);
si tel_number est plus grand que 15 bits, quel type de données puis-je utiliser, je ferais mieux d'utiliser Bigint(20) ?
create table address(
address varchar(255),
city varchar(255),
country varchar(255),
post_code int(11)
);
par exemple, si j'ai un code de pays pour le Canada, je peux utiliser +2 ou 002. Ce qui est mieux pour le traitement?
Merci pour vos conseils.
10 réponses
Eh bien, personnellement, je n'utilise pas le type de données numériques pour stocker des numéros de téléphone ou des informations connexes.
comment stockez-vous un nombre dit 001234567? Il finira en 1234567, perdant les zéros de tête.
bien sûr, vous pouvez toujours gauche-pad il vers le haut, mais c'est à condition que vous savez exactement combien de chiffres le nombre devrait être.
Ce n'est pas de répondre à l'ensemble de votre post,
Juste mes 2 cents
en Fait, vous pouvez utiliser un varchar pour un numéro de téléphone. Vous n'avez pas besoin d'un int parce que vous n'allez pas effectuer l'arithmétique sur les nombres.
les stocker comme deux champs pour les numéros de téléphone - un" numéro "et un" masque "comme TinyText types qui n'ont pas besoin de plus de 255 articles .
avant de stocker les fichiers, nous analysons le numéro de téléphone pour obtenir le formatage qui a été utilisé et qui crée le masque, nous stockons ensuite le numéro a chiffres seulement par exemple
entrée: (0123) 456 7890
Numéro: 01234567890
Masque: (nnnn)_nnn_nnnn
en théorie, cela nous permet D'effectuer des recherches comparatives sur le champ Nombre, comme obtenir tous les numéros de téléphone qui commencent par un code régional spécifique, sans avoir à se soucier de la façon dont il a été saisi par les utilisateurs
je stocke habituellement les numéros de téléphone comme un BIGINT dans le format E164.
E164 jamais commencer par un 0, avec les premiers chiffres étant le code du pays.
+441234567890
+44 (0)1234 567890
01234 567890
etc. serait stocké comme 441234567890 .
j'utiliserais un varchar pour les numéros de téléphone. de cette façon, vous pouvez également stocker + et (), qui est parfois vu dans les numéros tel (comme vous l'avez mentionné vous-même). et vous n'avez pas à vous soucier d'utiliser tous les bits des nombres entiers.
Je ne suis pas sûr que ce soit une bonne idée d'utiliser des entiers. Certains nombres peuvent contenir des caractères spéciaux (# dans le cadre de l'extension par exemple) que vous devriez être capable de gérer aussi. Je suggère donc d'utiliser des varchars à la place.
si stocker moins de 1 mil records, et haute performance n'est pas un problème allez pour varchar(20)/char(20) sinon j'ai trouvé que pour stocker même 100 milion global business phones ou téléphones personnels, int est préférable. Raison: touche plus petite -> vitesse de lecture/écriture plus élevée, aussi le formatage peut permettre des doublons.
1 téléphone dans char (20) = 20 octets vs 8 octets bigint (ou 10 vs 4 octets int pour les téléphones locaux, jusqu'à 9 Chiffres) , Moins d'entrées peuvent entrer le bloc d'index => plus de blocs => plus de recherches, consultez la section ce pour plus d'info (écrit pour Mysql, mais il devrait être vrai pour d'autres Bases de données Relationnelles).
voici un exemple de tables téléphoniques:
CREATE TABLE `phoneNrs` (
`internationalTelNr` bigint(20) unsigned NOT NULL COMMENT 'full number, no leading 00 or +, up to 19 digits, E164 format',
`format` varchar(40) NOT NULL COMMENT 'ex: (+NN) NNN NNN NNN, optional',
PRIMARY KEY (`internationalTelNr`)
)
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin
ou avec transformation/division avant insérer (2+2+4+1 = 9 bytes)
CREATE TABLE `phoneNrs` (
`countryPrefix` SMALLINT unsigned NOT NULL COMMENT 'countryCode with no leading 00 or +, up to 4 digits',
`countyPrefix` SMALLINT unsigned NOT NULL COMMENT 'countyCode with no leading 0, could be missing for short number format, up to 4 digits',
`localTelNr` int unsigned NOT NULL COMMENT 'local number, up to 9 digits',
`localLeadingZeros` tinyint unsigned NOT NULL COMMENT 'used to reconstruct leading 0, IF(localLeadingZeros>0;LPAD(localTelNr,localLeadingZeros+LENGTH(localTelNr),'0');localTelNr)',
PRIMARY KEY (`countryPrefix`,`countyPrefix`,`localLeadingZeros`,`localTelNr`) -- ordered for fast inserts
)
DEFAULT CHARSET=ascii
DEFAULT COLLATE=ascii_bin
;
aussi" le numéro de téléphone n'est pas un numéro", à mon avis est relatif au type de numéros de téléphone. Si nous parlons d'une phoneBook mobile interne, puis les chaînes sont très bien, que l'utilisateur peut souhaiter stocker codes de hachage GSM . Si vous stockez des téléphones E164 , bigint est la meilleure option.
envisager la normalisation au format E. 164 . Pour un soutien international complet, vous aurez besoin d'un VARCHAR de 15 chiffres.
Voir Twilio recommandation pour plus d'informations sur la localisation des numéros de téléphone.
INT (10) ne signifie pas un nombre à 10 chiffres, il signifie un entier avec une largeur d'affichage de 10 chiffres. La valeur maximale pour un INT dans MySQL est 2147483647 (ou 4294967295 si non signé).
vous pouvez utiliser un BIGINT au lieu de INT pour le stocker comme un numérique. Utiliser BIGINT vous économisera 3 octets par ligne sur VARCHAR(10).
Stocker "Pays + région + numéro séparément". Vous pouvez essayer D'utiliser un VARCHAR (20), cela vous permet la capacité de stocker les numéros de téléphone internationaux correctement, si besoin est.
varchar ou texte devrait être les meilleurs types de données pour stocker des numéros mobiles je suppose.