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

22

Puisque varchar prend un espace disque proportionnel à la taille du champ, y a-t-il une raison pour laquelle nous ne devrions pas toujours définir varchar comme maximum, par exemple varchar(8000)sur SQL Server?

Sur la table de création, si je vois quelqu'un faire, varchar(100)je devrais lui dire non, tu as tort, tu devrais faire varchar(8000)?

sql-server varchar

— Aleksandr Levchuk
source

Je pense que nous devons différencier ici entre l'utilisation dans la table de création et l'utilisation dans les déclarations de paramètres des procédures stockées. Pour la deuxième interprétation, voir ma question dba.stackexchange.com/questions/1772/…

— bernd_k

18

La longueur est une contrainte sur les données (comme CHECK, FK, NULL etc.)
Performances lorsque la ligne dépasse 8060 octets
Ne peut pas avoir de contrainte ou d'index unique (la largeur de la colonne clé doit être <900)
La valeur par défaut est SET ANSI PADDING ON = possibilité de stocker de nombreux espaces de fin
SQL Server supposera que la longueur moyenne est de 4000 pour les opérations de tri, allouant de la mémoire en fonction de cela (besoin de trouver un lien pour sauvegarder cela, mais rouillez-moi pendant que je le fais :-)

Résumé: ne le faites pas.

— gbn
source

Performances lorsque la ligne dépasse 8060 octets . Cela fait référence aux octets réels utilisés et non aux octets autorisés maximaux?

— bernd_k

@bernd_k: 8060 = plus grande quantité de données pour une ligne qui tient dans une seule page 8192. Inclure les frais généraux de ligne. Reste (132 octets) = surcharge de page

— gbn

Cela signifie que les performances diminuent lorsque la plus grande taille est réellement utilisée, et non par le simple fait, que son utilisation est autorisée.

— bernd_k

@bernd_k: toute diminution des performances est causée par 1. l'allocation de mémoire pour les tris, etc. 2. Le dépassement de ligne (> 8060 octets). Le fait d'avoir 10 caractères dans chaque varchar (8000) n'est pas pertinent tant que ces conditions ne sont pas remplies (SQL avertira plus tard d'éventuelles erreurs potentielles pour les clés d'index)

— gbn

Le tri d'une table avec une colonne varchar (100) remplie de champs de 100 octets vaut-il une autre question, car le tri suppose une moyenne de 50 caractères?

— bernd_k

7

En supposant que vous faites référence à SQL Server, je peux en penser un.

Il y a une limite à la taille (8 Ko) d'une ligne dans une table et SQL vous permet de définir des champs varchar qui pourraient théoriquement dépasser cette limite. Ainsi, l'utilisateur pourrait obtenir des erreurs s'il mettait trop de données dans le champ lié à cela.

À partir de SQL 2K8, vous pouvez dépasser cette limite, mais il y a des implications en termes de performances .

De plus, il y a toute la vérification du caractère raisonnable de limiter la taille à ce que vous attendez des données. Si vous voulez un champ de longueur illimité, pourquoi ne pas utiliser du texte ou du texte?

— JohnFx
source

de sorte que les types de données text et ntext sont stockés d'une manière qui n'affecte pas les performances?

— Chad

Ces types ne contribuent pas autant à la limite de taille de ligne de 8 Ko sur une table car les données réelles sont stockées dans une table distincte sous les couvertures au lieu d'être alignées avec le reste des colonnes. Il y a toujours un impact sur les performances, mais pour différentes raisons. Il existe également des limitations sur la prise en charge des fonctionnalités dans ces domaines par rapport à varchar et nvarchar

— JohnFx

text et ntext sont déconseillés au profit de varchar (max).

— Phil Helmer

3

Cela dépend sûrement des informations stockées sur le terrain?

Certaines choses vont avoir une longueur maximale pour un certain nombre de raisons et s'il doit y avoir une longueur maximale, cela devrait être la longueur de votre champ.

S'il n'y a théoriquement pas de longueur maximale, je me demanderais pourquoi varchar serait utilisé.

— Toby
source

3

Dans le contexte des bases de données Oracle, j'ai appris que toujours utiliser la plus petite taille de champ pour les colonnes de base de données a un piège.

Lorsque vous déplacez des données via l'importation / exportation d'une base de données avec un classement à un octet vers une base avec un classement à plusieurs octets (comme Oracle XE), la longueur en octets peut augmenter et l'importation des données dans les tables créées par l'importation échoue. Bien sûr, Oracle a la possibilité de définir la longueur de varchar2 sous forme de caractère ou d'octet.

Mon point ici, c'est qu'il n'est pas toujours sage de définir un champ avec toujours le plus petit possible. J'ai vu beaucoup de tables de modification pour augmenter le champ avec plus tard (en raison de modifications des exigences).

Avoir un champ inutilisé de 20% à 100% avec est une option discutable ici.

— bernd_k
source