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

Quelqu’un va donner une réponse bien meilleure que celle-ci, mais je voulais juste faire remarquer que personnellement, je ne stockerais jamais un numéro de téléphone dans un champ entier quelconque, principalement parce que:

1. Vous n’avez pas besoin de faire d’arithmétique, et
2. Tôt ou tard, quelqu’un essaiera de faire quelque chose comme mettre des parenthèses autour de son indicatif régional.

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

• INT (11) pour tout ce qui est soit un identifiant soit un autre identifiant
• DATETIME pour les horodatages
• VARCHAR (255) pour tout élément garanti inférieur à 255 caractères (titres de page, noms, etc.)
• TEXTE pour à peu près tout le rest.

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 très 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 et du nom de famille doivent comporter au moins 48 caractères – il existe des noms de certains pays, tels que la Malaisie ou l’Inde, qui sont très longs.

Les numéros de téléphone et les codes postaux que vous devez toujours traiter comme du texte, pas des nombres. La raison normale invoquée est qu’il existe des codes postaux commençant par 0, et dans certains pays, les numéros de téléphone peuvent également commencer par 0. Mais la vraie raison est qu’ils ne sont pas des numéros – ce sont des identifiants qui sont créés de chiffres (et cela ne tient pas compte des 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 les champs VARCHAR pour ce type d’informations. Bien que cela semble paresseux, cela signifie que vous n’avez pas à vous soucier de la bonne taille minimale.

Comme vous allez traiter des données de longueur variable (noms, adresses e-mail), vous voudrez utiliser VARCHAR. La quantité d’espace occupée par un champ VARCHAR est de [field length] + 1 octet, jusqu’à la longueur maximale de 255, donc je ne voudrais pas trop me soucier d’essayer de trouver une taille parfaite. Jetez un coup d’œil à ce que vous pourriez imaginer être la plus longue, puis doublez-le et définissez-le comme limite de VARCHAR. Cela dit…:

Je mets généralement les champs e-mail sur VARCHAR (100) – je n’ai pas encore trouvé de problème. Noms définis sur VARCHAR (50).

Comme les autres l’ont déjà dit, les numéros de téléphone et les codes postaux ne sont pas des valeurs numériques, ce sont des chaînes contenant les chiffres 0-9 (et parfois plus!). Vous devez donc les traiter comme une chaîne. VARCHAR (20) devrait suffire.

Notez que si vous stockez des numéros de téléphone sous forme d’entiers, de nombreux systèmes supposent 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 firebase database 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, le courrier électronique et les numéros, chacun avec une colonne NameID qui est une clé étrangère sur tout sauf la table Name, sur laquelle il s’agit de la clé en cluster principale. J’ai utilisé MainName et FirstName à la place de LastName et FirstName pour autoriser les entrées professionnelles ainsi que les entrées personnelles, mais vous n’en avez peut-être pas besoin.

La colonne NameID devient un smallint dans toutes les tables car je suis presque certain que je ne ferai pas plus de 32 000 entrées. Presque tout le rest est varchar (n) allant de 20 à 200, selon ce que vous voulez stocker (anniversaires, commentaires, emails, noms très longs). Cela dépend vraiment de ce que vous stockez.

La table de nombres est où je dévie 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 le rend dans la firebase database et que les données restnt très cohérentes. L’extension et les codes de pays que j’ai appelés nullibles, mais ceux-ci pourraient être varchar si vous le vouliez. PhoneType est varchar (20) et n’est pas nullable.

J’espère que cela t’aides!