Pourquoi ne pas spécifier chaque VARCHAR comme VARCHAR (65535) ?

Question

Étant donné que les exigences en matière de stockage pour un champ Varchar sont basées sur la longueur réelle de la chaîne saisie, quel serait l'inconvénient de spécifier chaque champ Varchar comme étant le maximum possible : Varchar (65535) ? En dehors d'un octet supplémentaire pour les champs de plus de 255 caractères ?

[Exigences de stockage pour les chaînes de longueur L : L + 1 octets si les valeurs de la colonne nécessitent de 0 à 255 octets, L + 2 octets si les valeurs peuvent nécessiter plus de 255 octets].

Merci !

Answer 1

De la documents - Limites du nombre de colonnes et de la taille des lignes des tableaux :

Chaque table (quel que soit le moteur de stockage) a une taille de ligne maximale de 65 535 octets. Les moteurs de stockage peuvent imposer des contraintes supplémentaires à cette limite, réduisant ainsi la taille maximale effective des lignes.

La taille maximale des lignes limite le nombre (et éventuellement la taille) des colonnes, car la longueur totale de toutes les colonnes ne peut pas dépasser cette taille. Par exemple, les caractères utf8 nécessitent jusqu'à trois octets par caractère, donc pour une colonne CHAR(255) CHARACTER SET utf8, le serveur doit allouer 255 × 3 = 765 octets par valeur. Par conséquent, une table ne peut pas contenir plus de 65 535 / 765 = 85 colonnes de ce type.

Le stockage des colonnes de longueur variable comprend des octets de longueur, qui sont évalués par rapport à la taille de la ligne. Par exemple, une colonne VARCHAR(255) CHARACTER SET utf8 nécessite deux octets pour stocker la longueur de la valeur, de sorte que chaque valeur peut prendre jusqu'à 767 octets.

Ainsi, en définissant un seul VARCHAR(65535) vous limite effectivement à une colonne une seule colonne sur la ligne (en supposant que vous l'ayez remplie).

Tout cela mis à part le fait qu'une taille aussi grande n'est pas du tout adaptée à certains types de données - si vous avez une colonne de numéros de téléphone qui peut contenir des numéros locaux et internationaux, vous pouvez choisir d'utiliser une taille de VARCHAR de le faire, mais le fixer à une valeur supérieure à 20 pourrait bien ne pas avoir de sens (je suis généreux).

Voir cette réponse de Bill Karwin, qui indique également que les performances peuvent être affectées si des tables temporaires sont générées avec des fichiers inutilement longs. VARCHAR (en raison de la conversion de ces champs en format CHAR et inversement - voir le billet pour plus de détails).

Answer 2

Creo que varchar La longueur des colonnes n'est pas seulement une question de stockage. Elles concernent également la sémantique des données.

C'est-à-dire qu'il faut spécifier un name colonne comme varchar(100) signifie que les noms stockés sur votre système ne doivent pas comporter plus de 100 caractères.

Du côté du stockage, ils devraient être les mêmes. Cependant, les estimations de la taille des rangées seraient plus précises avec une longueur spécifique sur varchar colonnes que sans elles (sans avoir besoin d'un système de collecte de statistiques conservant des distributions de données sur varchar tailles).

Answer 3

Une raison possible serait d'améliorer la compatibilité avec d'autres applications. Par exemple, si vous avez une application qui utilise un champ "product_no" de 100 caractères et que vous voulez vous interfacer avec une application qui utilise un champ similaire, comme "model_no", de 40 caractères, ce sera un problème. Tous les product_nos de votre application dont la longueur dépasse 40 caractères seraient tronqués et vous devriez trouver un moyen de les traduire entre les applications.

Answer 4

L'une des raisons est que la taille du champ est un contrôle des données saisies. Voulez-vous vraiment que quelqu'un saisisse un numéro de téléphone de 1000 caractères ? Avoir un champ trop grand est un moyen de garantir que des déchets seront saisis dans votre base de données. Vous aurez des numéros de téléphone qui diront des choses comme (exemple non pris au hasard) :

"ne parlez qu'à la grande blonde du bureau principal".

au lieu d'un vrai numéro de téléphone ou d'un champ de courrier électronique contenant des notes sur le client parce qu'ils n'ont pas de champ de notes ? Cela ne fonctionne pas très bien lorsque vous essayez de lui envoyer un courriel.

Les tables larges peuvent créer des problèmes qui leur sont propres dans les bases de données, car vous pouvez rencontrer des limites d'enregistrement inattendues (vous pouvez concevoir une table plus large que ce qui peut réellement être stocké dans un enregistrement, ce qui fait parfois échouer les insertions de manière inattendue) et des problèmes de performance lorsque les données se séparent sur les pages de données. Je sais que vous pouvez avoir ce genre de problèmes avec des tables larges dans SQL Server et je ne serais pas surpris que mysql rencontre des problèmes similaires. Un expert mysql devra vraiment s'occuper de ce problème. L'indexation peut aussi être un problème avec les champs larges. Le moteur de base de données peut être moins enclin à penser que l'index est utile. Encore une fois, je ne suis pas sûr que mysql ait ce problème mais c'est quelque chose à rechercher. Je sais que ce sont des problèmes liés à l'utilisation de la taille maximale des champs pour tout dans SQL Server, mysql peut avoir ces problèmes ou d'autres que SQL Server n'a pas.

Answer 5

Par exemple, le moteur MEMORY de MySQL ne supporte pas très bien les champs VARCHAR. Le moteur réserve pour chaque ligne la quantité maximale d'octets, et non la longueur réellement utilisée. Ainsi, si vous définissez une table avec une seule colonne VARCHAR(1000), vous aurez une utilisation de la mémoire de 1000*3 octets pour chaque ligne que vous ajoutez, même si ce sont des chaînes vides.