Champs MySQL courants et leurs types de données appropriés

Question

Je suis en train de mettre en place une toute petite base de données MySQL qui stocke le prénom, le nom, l'adresse électronique et le numéro de téléphone et j'ai du mal à trouver le type de données "parfait" pour chaque champ. Je sais qu'il n'existe pas de réponse parfaite, mais il doit y avoir une sorte de convention commune pour les champs couramment utilisés tels que ceux-ci. Par exemple, j'ai déterminé qu'un numéro de téléphone américain non formaté est trop grand pour être stocké en tant que unsigned int, il doit être au moins un bigint.

Parce que je suis sûr que d'autres personnes trouveront probablement cela utile, je ne veux pas limiter ma question aux seuls champs que j'ai mentionnés ci-dessus.

Quels types de données conviennent aux champs courants des bases de données ? Des champs comme le numéro de téléphone, l'adresse électronique et l'adresse postale ?

Answer 1

Quelqu'un va poster une bien meilleure réponse que celle-ci, mais je voulais simplement souligner que, personnellement, je ne stockerai jamais un numéro de téléphone dans un champ de type entier, principalement parce que.. :

1. Vous n'avez pas besoin de faire de l'arithmétique avec ça, et
2. Tôt ou tard, quelqu'un va essayer de (faire quelque chose comme) mettre des parenthèses autour de son code régional.

En général, cependant, j'utilise presque exclusivement.. :

• INT(11) pour tout ce qui est soit un identifiant, soit une référence à un autre identifiant.
• DATETIME pour les horodateurs
• VARCHAR(255) pour tout ce qui doit contenir moins de 255 caractères (titres de pages, noms, etc.).
• TEXTE pour à peu près tout le reste.

Bien sûr, il y a des exceptions, mais je trouve que cela couvre la plupart des éventualités.

Answer 2

Voici quelques types de données courants que j'utilise (mais je ne suis pas un grand professionnel) :

| Column           | Data type     | Note
| ---------------- | ------------- | -------------------------------------
| id               | INTEGER       | AUTO_INCREMENT, UNSIGNED                                                          |  
| uuid             | CHAR(36)      | or CHAR(16) binary                                                                |  
| title            | VARCHAR(255)  |                                                                                   |  
| full name        | VARCHAR(70)   |                                                                                   |  
| gender           | TINYINT       | UNSIGNED                                                                          |  
| description      | TINYTEXT      | often may not be enough, use TEXT 
                                     instead          
| post body        | TEXT          |                                                                                   |  
| email            | VARCHAR(255)  |                                                                                   |  
| url              | VARCHAR(2083) | MySQL version < 5.0.3 - use TEXT                                                  |  
| salt             | CHAR(x)       | randomly generated string, usually of 
                                     fixed length (x)    
| digest (md5)     | CHAR(32)      |                                                                                   |  
| phone number     | VARCHAR(20)   |                                                                                   |  
| US zip code      | CHAR(5)       | Use CHAR(10) if you store extended 
                                     codes      
| US/Canada p.code | CHAR(6)       |                                                                                   |  
| file path        | VARCHAR(255)  |                                                                                   |  
| 5-star rating    | DECIMAL(3,2)  | UNSIGNED                                                                          |  
| price            | DECIMAL(10,2) | UNSIGNED                                                                          |  
| date (creation)  | DATE/DATETIME | usually displayed as initial date of 
                                     a post                                       |  
| date (tracking)  | TIMESTAMP     | can be used for tracking changes in a 
                                     post                                        |  
| tags, categories | TINYTEXT      | comma separated values *                                                          |  
| status           | TINYINT(1)    | 1 – published, 0 – unpublished, … You 
                                     can also use ENUM for human-readable 
                                     values
| json data        | JSON          | or LONGTEXT

Answer 3

D'après mon expérience, les champs prénom/nom doivent comporter au moins 48 caractères. Certains noms de pays comme la Malaisie ou l'Inde sont très longs dans leur forme complète.

Numéros de téléphone et codes postaux que vous devriez toujours traiter comme du texte et non comme des chiffres. La raison habituelle est qu'il y a des codes postaux qui commencent par 0, et dans certains pays, les numéros de téléphone peuvent aussi commencer par 0. numéros -- ils sont identifiants qui se trouvent être constitués de chiffres (et cela sans tenir compte des pays comme le Canada dont les codes postaux comportent des lettres). Il faut donc les stocker dans un champ de texte.

Dans MySQL, vous pouvez utiliser des champs VARCHAR pour ce type d'information. Bien que cela semble paresseux, cela signifie que vous n'avez pas à vous préoccuper de la taille minimale appropriée.

Answer 4

Étant donné que vous allez traiter des données de longueur variable (noms, adresses électroniques), il est préférable d'utiliser VARCHAR. La quantité d'espace occupée par un champ VARCHAR est la suivante [field length] + 1 octet, jusqu'à une longueur maximale de 255, donc je ne m'inquiéterais pas trop d'essayer de trouver une taille parfaite. Regardez ce que vous imaginez être la longueur la plus longue, puis doublez-la et définissez-la comme votre limite VARCHAR. Cela dit.. :

Je configure généralement les champs de courrier électronique en VARCHAR(100) - je n'ai pas encore rencontré de problème à ce sujet. Les noms sont définis en VARCHAR(50).

Comme les autres l'ont dit, les numéros de téléphone et les codes postaux ne sont pas réellement des valeurs numériques, ce sont des chaînes contenant les chiffres 0-9 (et parfois plus !), et vous devez donc les traiter comme une chaîne. VARCHAR(20) devrait être bien suffisant.

Notez que si vous stockez les numéros de téléphone sous forme d'entiers, de nombreux systèmes supposeront qu'un numéro commençant par 0 est un numéro octal (base 8) ! Par conséquent, le numéro de téléphone parfaitement valide "0731602412" serait placé dans votre base de données sous la forme du nombre décimal "124192010" ! !!

Answer 5

Je fais à peu près la même chose, et voici ce que j'ai fait.

J'ai utilisé des tables séparées pour le nom, l'adresse, l'email et les numéros, chacune avec une colonne NameID qui est une clé étrangère sur tout sauf la table Name, sur laquelle elle est la clé primaire clusterisée. J'ai utilisé MainName et FirstName au lieu de LastName et FirstName pour tenir compte des entrées professionnelles et personnelles, mais vous n'en aurez peut-être pas besoin.

La colonne NameID doit être un petit nombre dans toutes les tables, car je suis pratiquement certain que je ne ferai pas plus de 32 000 entrées. Presque tout le reste est un varchar(n) allant de 20 à 200, en fonction de ce que vous voulez stocker (anniversaires, commentaires, emails, noms vraiment longs). Cela dépend vraiment du type de choses que vous voulez stocker.

C'est dans la table des nombres que je m'en écarte. Je l'ai configurée pour avoir cinq colonnes intitulées NameID, Phone#, CountryCode, Extension, et PhoneType. J'ai déjà parlé de NameID. Phone# est un varchar(12) avec une contrainte de contrôle ressemblant à ceci : CHECK (Phone# like '[0-9][0-9][0-9]-[0-9][0-9][0-9]-[0-9][0-9][0-9][0-9][0-9][0-9]'). Cela permet de s'assurer que seuls les éléments que je veux sont intégrés dans la base de données et que les données restent très cohérentes. Les codes d'extension et de pays ont été appelés nullable smallints, mais ils pourraient être varchar si vous le souhaitiez. PhoneType est un varchar(20) et n'est pas nullable.

J'espère que cela vous aidera !