Aucun SGBD que je connaisse n'a d'"optimisation" qui créera un VARCHAR avec un 2^n length fonctionne mieux qu'un avec un max longueur qui n'est pas une puissance de 2.
Je pense que les premières versions de SQL Server traitaient en fait un VARCHAR avec une longueur 255 différente de celle avec une longueur maximale plus élevée. Je ne sais pas si c'est toujours le cas.
Pour presque tous les SGBD, le stockage réel requis n'est déterminé que par le nombre de caractères que vous y mettez, et non par le max longueur que vous définissez. Donc, du point de vue du stockage (et très probablement aussi des performances), cela ne fait aucune différence si vous déclarez une colonne comme VARCHAR(100) ou VARCHAR(500) .
Vous devriez voir le max longueur fournie pour un VARCHAR colonne comme une sorte de contrainte (ou de règle métier) plutôt qu'un élément technique/physique.
Pour PostgreSQL, la meilleure configuration consiste à utiliser text sans restriction de longueur et CHECK CONSTRAINT qui limite le nombre de caractères à tout ce dont votre entreprise a besoin.
Si cette exigence change, la modification de la contrainte de vérification est beaucoup plus rapide que la modification de la table (car la table n'a pas besoin d'être réécrite)
La même chose peut être appliquée pour Oracle et d'autres - dans Oracle, ce serait VARCHAR(4000) au lieu de text mais.
Je ne sais pas s'il existe une différence de stockage physique entre VARCHAR(max) et par ex. VARCHAR(500) dans SQL Server. Mais apparemment, il y a un impact sur les performances lors de l'utilisation de varchar(max) par rapport à varchar(8000) .
Voir ce lien (posté par Erwin Brandstetter en commentaire)
Modifier 2013-09-22
Concernant le commentaire de bigown :
Dans les versions Postgres antérieures à 9.2 (qui n'étaient pas disponibles lorsque j'ai écrit la réponse initiale), une modification de la définition de colonne did réécrivez tout le tableau, voir par ex. ici . Depuis la 9.2 ce n'est plus le cas et un test rapide a confirmé que l'augmentation de la taille des colonnes d'un tableau de 1,2 million de lignes ne prenait en effet que 0,5 seconde.
Pour Oracle, cela semble également vrai, à en juger par le temps nécessaire pour modifier le varchar d'une grande table colonne. Mais je n'ai trouvé aucune référence pour cela.
Pour MySQL le manuel indique
"Dans la plupart des cas, ALTER TABLE fait une copie temporaire de la table d'origine ". Et mes propres tests le confirment :exécuter un ALTER TABLE sur une table avec 1,2 million de lignes (le même que dans mon test avec Postgres) pour augmenter la taille d'une colonne a pris 1,5 minutes. Dans MySQL, cependant, vous ne pouvez pas utilisez la "solution de contournement" pour utiliser une contrainte de vérification afin de limiter le nombre de caractères dans une colonne.
Pour SQL Server, je n'ai pas trouvé d'énoncé clair à ce sujet, mais le temps d'exécution pour augmenter la taille d'un varchar colonne (encore une fois le tableau de 1,2 million de lignes ci-dessus) indique que non la réécriture a lieu.
Modifier 2017-01-24
Il semble que je me sois (au moins partiellement) trompé sur SQL Server. Voir cette réponse d'Aaron Bertrand
qui montre que la longueur déclarée d'un nvarchar ou varchar colonnes fait une énorme différence pour la performance.
