MySQL: Pourquoi utiliser VARCHAR (20) au lieu de VARCHAR (255)?
Duplicata possible:
Y a-t-il des inconvénients à utiliser un varchar générique (255) pour tous les champs texte?
Dans MYSQL, vous pouvez choisir une longueur pour le type de champ VARCHAR. Les valeurs possibles sont 1-255.
Mais quels sont ses avantages si vous utilisez VARCHAR (255) qui est le maximum au lieu de VARCHAR (20)? Pour autant que je sache, la taille des entrées dépend uniquement de la longueur réelle de la chaîne insérée.
taille (octets) = longueur + 1
Donc, si vous avez le mot "Exemple" dans un champ VARCHAR (255), il aurait 8 octets. Si vous l'avez dans un champ VARCHAR (20), il aurait également 8 octets. Quelle est la différence?
J'espère que vous pouvez m'aider. Merci d'avance!
Découvrez: Référence pour Varchar
En bref, il n'y a pas beaucoup de différence à moins que vous ne dépassiez la taille de 255 dans votre VARCHAR qui nécessitera un autre octet pour le préfixe de longueur.
La longueur indique davantage une contrainte sur les données stockées dans la colonne qu'autre chose. Cela limite également la taille de stockage MAXIMUM de la colonne. À mon humble avis, la longueur devrait avoir un sens en ce qui concerne les données. Si vous stockez un numéro de sécurité sociale #, cela n'a aucun sens de définir la longueur à 128, même si cela ne vous coûte rien de stockage si tout ce que vous stockez est un SSN.
Il existe de nombreuses raisons valables pour choisir une valeur inférieure au maximum qui ne sont pas liées aux performances. La définition d'une taille permet d'indiquer le type de données que vous stockez et peut également agir comme une dernière forme de validation.
Par exemple, si vous stockez un code postal britannique, vous n'avez besoin que de 8 caractères. La définition de cette limite permet de clarifier le type de données que vous stockez. Si vous choisissez 255 caractères, cela ne ferait qu'embrouiller les choses.
Je ne connais pas mySQL mais dans SQL Server, il vous permettra de définir des champs tels que le nombre total d'octets utilisés soit supérieur au nombre total d'octets qui peuvent réellement être stockés dans un enregistrement. C'est une mauvaise chose. Tôt ou tard, vous obtiendrez une ligne où la limite est atteinte et vous ne pouvez pas insérer les données.
Il est préférable de concevoir la structure de votre base de données pour tenir compte des limites de taille de ligne.
De plus, oui, vous ne voulez pas que les gens mettent 200 caractères dans un champ où la valeur maximale doit être 10. Si c'est le cas, ce sont presque toujours des données incorrectes.
Vous dites, eh bien je peux limiter cela au niveau de l'application. Mais les données n'entrent pas dans la base de données à partir d'une seule application. Parfois, plusieurs applications l'utilisent, parfois les données sont importées et parfois elles sont corrigées manuellement à partir de la fenêtre de requête (mettez à jour tous les enregistrements pour ajouter 10% au prix par exemple). Si l'une de ces autres sources de données ne connaît pas les règles que vous mettez dans votre application, vous aurez de mauvaises données inutiles dans votre base de données. L'intégrité des données doit être appliquée au niveau de la base de données (ce qui ne vous empêche pas de vérifier également avant d'essayer d'entrer des données) ou vous n'avez aucune intégrité. De plus, d'après mon expérience, les personnes trop paresseuses pour concevoir leur base de données sont souvent trop paresseuses pour mettre les limites dans l'application et il n'y a aucun contrôle d'intégrité des données.
Ils ont un mot pour les bases de données sans intégrité des données - inutile.
Il y a une différence sémantique (et je crois que c'est la seule différence): si vous essayez de remplir 30 caractères non-espace dans varchar (20), cela produira une erreur, alors qu'il réussira pour varchar (255). Il s'agit donc avant tout d'une contrainte supplémentaire.
Eh bien, si vous souhaitez autoriser une entrée plus grande, ou limiter la taille de l'entrée peut-être.
Par exemple, vous pouvez avoir first_name en tant que VARCHAR 20, mais peut-être street_address en tant que VARCHAR 50 car 20 peut ne pas être assez d'espace. Dans le même temps, vous souhaiterez peut-être contrôler la taille de cette valeur.
En d'autres termes, vous avez défini un plafond de la taille d'une valeur particulière, en théorie pour éviter que la table (et potentiellement les entrées d'index/d'index) ne deviennent trop grandes.
Vous pouvez simplement utiliser CHAR qui est également une largeur fixe, mais contrairement à VARCHAR qui peut être plus petit, CHAR remplit les valeurs (bien que cela rend l'accès SQL plus rapide.
Du point de vue des performances de la base de données, je ne pense pas qu'il y aura de différence.
Cependant, je pense qu'une grande partie de la décision sur la durée d'utilisation se résume à ce que vous essayez d'accomplir et à documenter le système pour accepter uniquement les données dont il a besoin.