Comment les longues colonnes impactent-elles les performances et l'utilisation du disque?
Dans notre projet actuel, il arrive trop souvent que nous devions étendre les colonnes de quelques caractères. De varchar(20) à varchar(30) et ainsi de suite.
En réalité, à quel point est-ce vraiment important? À quel point est-ce optimisé? Quel est l'impact de n'autoriser que 100, 200 ou même 500 caractères pour les champs "d'entrée" normaux? Un e-mail ne peut contenir que 320 caractères, donc ok - il y a une bonne limite. Mais qu'est-ce que je gagne si je le mets à 200, car je ne m'attends pas à des adresses e-mail plus longues que cela.
Habituellement, nos tableaux ne comporteront pas plus de 100 000 lignes et jusqu'à 20 ou 30 colonnes de ce type.
Nous utilisons maintenant SQL Server 2008, mais il serait intéressant de savoir comment les différentes bases de données gèrent ces problèmes.
Dans le cas où l'impact est très faible - comme je m'y attendais, cela aiderait à obtenir de bons arguments (sauvegardés avec des liens?) Pour convaincre mon DBA, que cette paranoïa à long champ n'est pas vraiment nécessaire.
Si c'est le cas, je suis ici pour apprendre :-)
La réponse spécifique à votre question (au moins pour Oracle et probablement d'autres bases de données) est que la longueur du champ n'a pas d'importance, seulement la longueur des données. Cependant, cela ne doit pas être utilisé comme facteur déterminant pour définir si le champ doit avoir sa longueur maximale autorisée ou non. Voici quelques autres problèmes que vous devriez considérer avant de maximiser la taille des champs.
Formatage Tout outil client qui formate les données en fonction de la taille des champs nécessitera des considérations de formatage spéciales. Par exemple, SQL * Plus d'Oracle affiche par défaut la taille maximale des colonnes Varchar2 même si les données ne comportent qu'un caractère. Comparer…
create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;
Mauvaises données La longueur du champ fournit un mécanisme supplémentaire pour capturer/empêcher les mauvaises données. Une interface ne doit pas essayer d'insérer 3000 caractères dans un champ de 100 caractères, mais si ce champ est défini comme étant de 4000 caractères, c'est possible. L'erreur ne serait pas détectée à l'étape de la saisie des données, mais le système peut avoir des problèmes plus bas lorsqu'une autre application essaie de traiter les données et les étranglements. Par exemple, si vous décidez ultérieurement d'indexer le champ dans Oracle, vous dépasserez la longueur de clé maximale (selon la taille du bloc et la concaténation). Voir…
create index i1 on f1(a);
Mémoire Si l'application cliente alloue de la mémoire en utilisant la taille maximale, l'application allouerait beaucoup plus de mémoire que nécessaire. Il faudrait prendre des précautions particulières pour éviter cela.
Documentation La taille du champ fournit un autre point de données de documentation sur les données. Nous pourrions appeler toutes les tables t1, t2, t3, etc. et tous les champs f1, f2, f3, etc., mais en spécifiant des noms significatifs, nous comprenons mieux les données. Par exemple, si une table d'adresses pour une entreprise avec des clients aux États-Unis a un champ appelé État qui comprend deux caractères, nous nous attendons à ce que l'abréviation d'état à deux caractères y soit incluse. D'un autre côté, si le champ comporte une centaine de caractères, nous pouvons nous attendre à ce que le nom complet de l'état apparaisse dans le champ.
Cela dit, il semble prudent de se préparer au changement. Ce n'est pas parce que tous les noms de vos produits contiennent aujourd'hui 20 caractères qu'ils le seront toujours. N'exagérez pas et n'en faites pas 1000, mais laissez de la place pour une expansion plausible.
Voici un bon point de départ pour vous.
http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx
J'ai peut-être mal compris votre question initiale. Laissez-moi voir si je peux vous trouver quelques autres liens pour référence.
Voici une bonne référence sur les sélections de types de données: http://sqlfool.com/2009/05/performance-considerations-of-data-types/
Passer de varchar (20) à varchar (30) peut sembler quelque chose de petit, mais vous devez en savoir plus sur le fonctionnement des structures de base de données afin d'être conscient des problèmes potentiels. Par exemple, aller à varchar (30) pourrait vous pousser au-delà du point de basculement de vos colonnes (si les 30 octets sont utilisés) pouvant être stocké sur une page (moins de 8060 octets). Cela entraînera une augmentation de l'espace disque utilisé, une diminution des performances et même une surcharge supplémentaire avec vos journaux de transactions.
Voici un lien pour les structures de base de données: http://technet.Microsoft.com/en-us/sqlserver/gg313756.aspx
En voici un pour les fractionnements de page et la journalisation trx: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx
HTH
Je pensais partager un autre point intéressant, que j'ai trouvé dans ne question de débordement de pile .
Réponse originale de: Nick Kavadias
Une raison de NE PAS utiliser les champs max ou texte est que vous ne pouvez pas effectuer reconstructions d'index en ligne c'est-à-dire RECONSTRUIRE AVEC ONLINE = ON même avec SQL Server Enterprise Edition.
Je considérerais cela comme un gros inconvénient lors de l'ajout arbitraire de colonnes n/varchar (max), et selon le site MS, cette restriction contre les reconstructions d'index en ligne reste dans SQL Server 2008, 2008 R2 et Denali; il n'est donc pas spécifique à SQL Server 2005.
Dans certains cas, la quantité d'espace que vous allouez pour un champ varchar affectera la quantité de mémoire allouée pour les tris en mémoire.
J'ai trouvé les présentations sur SQLWorkshops.com stimulantes, cette présentation parle d'un cas où un tri pour une commande déborde dans tempdb car il n'y a pas assez de mémoire allouée pour les champs char/varchar.
http://webcasts2.sqlworkshops.com/webcasts.asp
Cette webémission a également été présentée comme un article sur le site Web suivant:
http://www.mssqltips.com/tip.asp?tip=1955
Notez dans cette présentation que la colonne en cours de tri n'est pas la colonne char/varchar, mais la quantité d'espace allouée à la colonne varchar en mémoire fait une différence dans les performances de la requête dans certains cas.
SET ANSI_PADDING ON?
Vous vous retrouvez avec beaucoup d'espaces de fuite ...
Il ne concerne que l'espace disque et la longueur des caractères. Bien sûr, la recherche sur les types de données char et les index sur ces types de données agira plus lentement que l'entier, mais c'est une autre discussion.
Le type de données Varchar est un type de données "variable", donc si vous définissez une limite de varchar (500), il s'agit de la longueur maximale de caractères pour ce champ. La longueur minimale peut être comprise entre 0 et 500. En revanche, l'espace disque revendiqué sera différent pour les champs de 10, 30 ou 500 caractères.
J'ai parfois fait un test pour le type de données varchar (800) et pour les valeurs nulles, j'avais 17 octets utilisés, et pour chaque caractère inséré, il a ajouté un octet de plus. Par exemple, une chaîne de 400 caractères avait 417 octets utilisés sur le disque.
Je ne pense pas qu'il y ait une différence entre les tables créées avec des colonnes de varchar (20) ou varchar ((8000), tant que la longueur maximale réelle est <= 20.
D'un autre côté, dans certains cas, donner aux utilisateurs la possibilité de stocker des chaînes plus longues pourrait les encourager à le faire.