Discussion :

[Spoutnik]

Hello,

Y a t il un inconvénient (quel qu'il soit : optimisation du moteur, transmission réseau ...) à utiliser un varchar (5000) au lieu d'un varchar (256) par exemple ?

En gros, y a t il un inconvénient à utiliser la capacité max des varchar même si on sait qu'on ne va jamais l'utiliser au max ?

Merci d'avance.
++

[rudib]

Bonjour,

Je commets l'indélicatesse de répondre sans avoir croisé d'informations précises sur le sujet, j'espère que tu ne m'en tiendras pas rigueur... c'est un comportement compulsif

Cela peut dépendre du SGBD et donc du moteur de stockage. Je ne sais pas quel SGBD a un max length de 5000. SQL Server est limité (plus vraiment exact en version 2005) à 8000, MySQL 5 à 65535 (http://dev.mysql.com/doc/refman/5.0/en/char.html), PostgreSQL ça va très loin, Firebird/Interbase : 32k, Oracle et DB2 je ne sais pas.
Je pense que pour la plupart des SGBD, il n'y a pas de différence de performance dû à la taille maximale déclarée des varchar. Quand la donnée réellement stockée est petite, elle est lue directement dans la page de donnée, ou toute unité d'I/0 géré par le moteur de stockage.

En ce qui concerne le trafic réseau, cela ne change rien. Ce qui est renvoyé au client est un jeu de résultat qui contient seulement les données, et pas de subtilités de stockage qui concernent seulement le serveur.

Pour quelques moteurs de stockage, comme le MyISAM de MySQL, il y a une différence de performance entre CHAR et VARCHAR dûe à la nécessité de retrouver la taille de la donnée ou de savoir ou elle se trouve par pointeur dans l'enregistrement. Mais de varchar à varchar, cela doit être identique.

Là où cela peut poser problème, ce n'est pas dans la déclaration de la taille, mais dans son utilisation : évidemment plus le volume des données est important, plus la lecture est coûteuse, et selon le SGBD, des mécanismes de dépassement ou de pointeur obligent à sortir de la page lorsque la donnée ne tient plus dans l'unité d'I/O.

Quelques liens d'infos pour PostreSQL et Firebird.
http://www.postgresql.org/docs/8.2/i...character.html
http://www.volny.cz/iprenosil/interb...ib_strings.htm
http://www.ibphoenix.com/main.nfs?a=...page=ibp_blobs

[Spoutnik]

Hello,

Merci de commettre l'indélicatesse de me répondre

Pour préciser, la valeur de 5000 est juste indicative. Je me posais la question pour un chemin de fichier à enregistrer.
Merci beaucoup pour tes infos et les liens, tout ceci conforte mon opinion "intuitive".

++

[SQLpro]

3 choses

1) SQL Server 2005 est limité à 4 294 967 295 en VARCHAR et 2 147 483 647 en NVARCHAR.

2) la longeur importe peu si la sémantique l'exige. Autrement dit stocker 3000 caractères s'il n'y a pas de traitement derière ne sert par à grand chose. Allez vous faire du =, du LIKE sur cette colonne ?

3) plus les données sont courte et moins il y a de volume à traiter et plus les temps de réponse sont court. Il y aura toujours un imbécile d'utilisateur pour mettre 5000 caractère dans cette colonne !

A +

[Antoun]

Si la colonne est déclarée en VARCHAR(5000), mais que les données ne dépassent pas 50 caractères, les traitements seront-ils aussi rapides que si la colonne était déclarée en VARCHAR(50) ?

[Spoutnik]

Hello,

2) la longeur importe peu si la sémantique l'exige. Autrement dit stocker 3000 caractères s'il n'y a pas de traitement derière ne sert par à grand chose. Allez vous faire du =, du LIKE sur cette colonne ?

Il n'y a pas de traitement. Il s'agit uniquement de stockage "simple" d'un path de fichier. Pas de like/'=' ou autre opération.

3) plus les données sont courte et moins il y a de volume à traiter et plus les temps de réponse sont court. Il y aura toujours un imbécile d'utilisateur pour mettre 5000 caractère dans cette colonne !

ok, mais en terme d'espace de stockage disque, les 2 sont bien équivalents?

Merci de vos réponses.

[rudib]

Bonjour,

Autant que je sache, c'est équivalent, et de même rapidité, sans doute dans la plupart des moteurs de stockage.
Le fait de pouvoir prédéterminer la taille d'un varchar est plus lié au typage fort des colonnes (= contraintes de domaine = intégrité de la structure des données) qu'à des contraintes techniques.

Mais bon, c'est sauf méconnaissance de ma part.

[Spoutnik]

C'est ce que je pense aussi, mais bon, je voulais être sûr

merci !

[Fabien Celaia]

Equivalent et perf, mais "sale" d'un point de vue modélisation, et pas prudent (cf les utilisateurs de SQLPro )