Largeur de colonne SQL Server VARCHAR

En recherchant sur le Web, j'ai trouvé des conseils contradictoires sur la question de savoir s'il y a un impact sur les performances lors de la spécification de colonnes VARCHAR trop larges, par exemple VARCHAR (255) lorsque VARCHAR (30) fera probablement l'affaire.

Je vois toujours un accord qu'il y a un impact sur les performances si la ligne entière dépasse 8060 octets. À part cela, je vois un désaccord.

Est-ce vrai The default is SET ANSI PADDING ON = potential for lots of trailing spaces? Tant que la largeur totale des lignes est inférieure à 8060, y a-t-il de réels problèmes de performances dans le surdimensionnement des colonnes VARCHAR?

Preuve que la largeur des colonnes est importante

The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/

• Length is a constraint on the data (like CHECK, FK, NULL etc)
• Performance when the row exceeds 8060 bytes
• Can not have unique constraint or index (key column width must be < 900)
• The default is SET ANSI PADDING ON = potential for lots of trailing spaces

Quelles sont les conséquences de la configuration de varchar (8000)?

Preuve que la largeur de colonne N'A PAS D'IMPORTANCE

If you're talking about varchar and nvarchar then no, there is no penalty for allowing a higher field length.

/programming/7025996/overstating-field-size-in-database-design

The varchar datatype, by contrast, consumes only the amount of actual space used plus 2 bytes for overhead

http://sqlfool.com/content/PerformanceConsiderationsOfDataTypes.pdf

La question pourrait être mieux formulée comme suit:

"Quel est l'avantage de sur-spécifier la longueur maximale d'une colonne de longueur variable?"

En général, il y a peu d'avantages et plusieurs inconvénients comme le soulignent les différentes réponses liées. En dehors de toute autre préoccupation, considérez que SQL Server n'est pas open-source: il existe de nombreux «nombres magiques» et heuristiques appliqués en fonction des informations fournies au système. Sans accès au code source, nous ne pourrions jamais être entièrement sûrs de l'impact de cette pratique.

Dans certains cas , lorsque la longueur moyenne d'une colonne est nettement supérieure aux 50% supposés par SQL Server lors du calcul des octrois de mémoire de tri / hachage, vous pouvez constater une amélioration des performances en sur-spécifiant la longueur maximale. Il s'agit d'une solution de contournement douteuse , et ne devrait probablement être appliquée que par une explicite CASTou CONVERT(avec des commentaires!) Plutôt que de changer la définition de la colonne de base. Parfois, il sera préférable de réécrire la requête pour trier les clés au lieu de lignes entières de toute façon.

Lorsque la taille de ligne maximale peut dépasser la limite en ligne (même si aucune ligne ne le fait réellement), la suppression de lignes peut entraîner un fractionnement de page inattendu si un déclencheur est présent. Les mises à jour peuvent également entraîner une fragmentation via le même mécanisme.

SQL Server fait un très bon travail dans la plupart des cas où il est fourni des informations correctes et précises à partir des métadonnées. Compromettre ce principe pour la «commodité» me semble imprudent. Une approche judicieuse consiste à choisir une valeur de longueur maximale raisonnable en fonction des données réelles à stocker et de tout changement prévisible.

Comme vous l'avez indiqué, tant que la taille de la ligne ne dépasse pas 8060 (ou quel que soit le maximum défini), il n'y a pas de différence de performances dans l'utilisation de VARCHAR (30) ou VARCHAR (255) ou plus. La comparaison CHAR à VARCHAR de l'article lié n'est pas vraiment pertinente. Bien que je convienne que vous ne devez pas spécifier plus d'espace que ce dont vous êtes sûr d'avoir besoin, dans de nombreux cas, vous ne savez pas exactement combien d'espace vous aurez réellement besoin. Soyez donc libéral avec l'espace VARCHAR - je suis sûr que l'augmentation de la taille des champs nécessite une reconstruction de table, tandis que la diminution est une simple instruction ALTER TABLE.