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

Je mets en place une très petite base de données MySQL qui stocke le prénom, le nom, l'adresse e-mail 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'y a pas de réponse parfaite, mais il doit y avoir une sorte de convention commune pour des domaines couramment utilisés comme ceux-ci. Par exemple, j'ai déterminé qu'un numéro de téléphone américain non formaté est trop gros pour être stocké en tant qu'int non signé, 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 sont appropriés pour les champs de base de données courants? Des champs comme le numéro de téléphone, l'adresse e-mail et l'adresse?

Quelqu'un va publier une bien meilleure réponse que celle-ci, mais voulait juste faire remarquer que personnellement, je ne stockerais jamais un numéro de téléphone dans aucun type de champ entier, principalement parce que:

1. Vous n'avez pas besoin de faire d'arithmétique avec, et
2. Tôt ou tard, quelqu'un essaiera de (faire quelque chose comme) mettre des crochets autour de son indicatif régional.

En général cependant, je semble utiliser presque exclusivement:

• INT (11) pour tout ce qui est soit un ID ou référence un autre ID
• DATETIME pour les horodatages
• VARCHAR (255) pour tout ce qui est garanti à moins de 255 caractères (titres de page, 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.

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

| 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       

D'après mon expérience, les champs du prénom / nom doivent contenir au moins 48 caractères - il existe des noms de certains pays comme la Malaisie ou l'Inde qui sont très longs dans leur forme complète.

Les numéros de téléphone et les codes postaux doivent toujours être traités comme du texte et non comme des chiffres. La raison normale invoquée 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. Mais la vraie raison est que ce ne sont pas des nombres - ce sont des identifiants qui se trouvent être composés de chiffres numériques (et cela ignore les pays comme le Canada qui ont des lettres dans leurs codes postaux). Alors stockez-les dans un champ de texte.

Dans MySQL, vous pouvez utiliser des champs VARCHAR pour ce type d'informations. Bien que cela semble paresseux, cela signifie que vous n'avez pas à vous soucier trop de la bonne taille minimale.

Puisque vous allez avoir affaire à des données de longueur variable (noms, adresses e-mail), alors vous voudrez utiliser VARCHAR. La quantité d'espace occupée par un champ VARCHAR est de [field length]+ 1 octets, jusqu'à une longueur maximale de 255, donc je ne m'inquiéterais pas trop d'essayer de trouver une taille parfaite. Jetez un œil à ce que vous imaginez être la longueur la plus longue, puis doublez-la et définissez-la comme votre limite VARCHAR. Cela dit...:

Je définis généralement les champs de messagerie sur VARCHAR (100) - je n'ai pas encore rencontré de problème à ce sujet. Noms que j'ai mis à VARCHAR (50).

Comme les autres l'ont dit, les numéros de téléphone et les codes postaux / zip 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 nombre commençant par 0 est un nombre octal (base 8)! Par conséquent, le numéro de téléphone parfaitement valide "0731602412" serait mis dans votre base de données en tant que nombre décimal "124192010" !!

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'adresse e-mail et les nombres, chacune avec une colonne NameID qui est une clé étrangère sur tout sauf la table Name, sur laquelle il s'agit de la clé principale en cluster. J'ai utilisé MainName et FirstName au lieu de LastName et FirstName pour permettre les entrées professionnelles ainsi que les entrées personnelles, mais vous n'en avez peut-être pas besoin.

La colonne NameID devient une petite partie de toutes les tables car je suis assez certain que je ne ferai pas plus de 32000 entrées. Presque tout le reste est varchar (n) allant de 20 à 200, selon ce que vous voulez stocker (anniversaires, commentaires, e-mails, noms très longs). Cela dépend vraiment du type de choses que vous stockez.

La table des nombres est l'endroit où je m'écarte de cela. Je l'ai configuré pour avoir cinq colonnes intitulées NameID, Phone #, CountryCode, Extension et PhoneType. J'ai déjà discuté de NameID. Le numéro de téléphone est varchar (12) avec une contrainte de vérification ressemblant à ceci: CHECK (numéro de téléphone comme '[0-9] [0-9] [0-9] - [0-9] [0-9] [0 -9] - [0-9] [0-9] [0-9] [0-9] '). Cela garantit que seul ce que je veux entre dans la base de données et que les données restent très cohérentes. L'extension et les codes de pays que j'ai appelés nullable smallints, mais ceux-ci pourraient être varchar si vous le souhaitez. PhoneType est varchar (20) et n'est pas nullable.

J'espère que cela t'aides!