Bonjour,
J'ai pris l'habitude d'utiliser varchar(max) partout dans mes procédures stockées..
Est ce que cela peut impacter les performances ?
Vaut il mieux restreindre la taille du varchar quand on le peut ?
D'avance merci
Version imprimable
Bonjour,
J'ai pris l'habitude d'utiliser varchar(max) partout dans mes procédures stockées..
Est ce que cela peut impacter les performances ?
Vaut il mieux restreindre la taille du varchar quand on le peut ?
D'avance merci
plus la taille est restreinte, moins on utilise de place, et de mémoire et moins il y a besoin de ressource pour interroger, trouver... ces informations.
tu veux dire la taille réelle de la donnée qui est réellement mise dans le varchar ou le simple fait de déclarer un varchar dans la procédure stockée ??
Car je crois que la taille utilisée par un varchar est la taille réelle + 2 octets.
D'où le fait que j'ai toujours cru qu'un varchar(max) et un varchar(100) par exemple, étaient identique en mémoire.. mais je me trompe peut être.
Et que se passe t'il dans une procédure stockée, dans laquelle on rempli plusieurs fois des données (de longueurs différentes) dans un varchar déclaré en MAX ?
Merci
Personellement je ne pense pas que tu aies un impact sur tes performances.
On peut remarquer qu'un varchar prend en taille n+2bytes ou n est le nombre de caractères qu'il contient.Citation:
varchar [ ( n | max ) ]
Variable-length, non-Unicode character data. n can be a value from 1 through 8,000. max indicates that the maximum storage size is 2^31-1 bytes. The storage size is the actual length of data entered + 2 bytes. The data entered can be 0 characters in length. The SQL-2003 synonyms for varchar are char varying or character varying.
Les 2 bytes supplémentaires servent de descripteur de variable, ils contiennent la longueur de la chaine en fait si mes souvenirs sont corrects.
Donc d'après moi utiliser du varchar(max) partout n'aura pas vraiment d'impact sur tes performances. Par contre je verrais plus un probleme de qualité de données, voir de sécurité...
En effet, si tu récupères des données , par exemple, d'un formulaire sur le net, définir une taille maximum pour les champs peut te permettre de déja filtrer certaines "mauvaises informations" ainsi que d'éviter de te rammasser un script de 2^31-1 bytes (la capacité max du varchar(max)) d'inject sql par exemple.
De plus, définir des tailles maximum te permet en relisant le code d'avoir directement un apercu de ton modèle de données.
Voila mon avis sur la chose, et vos avis m'interessent :)
Salut Ptit_Dej,
D'accord avec toi..
Mais un avantage à utiliser les varchar(max) pourrait être que lorsque tu as besoin d'augmenter la taille d'un champ d'une table (ce qui arrive parfois), tu n'ais pas à revenir sur tout ton code SQL dans tes procédures stockées et autres objets pour modifier les varchar(50) en varchar(100) par exemple..
Ceci dit, les inject sql sont contrées par les requêtes paramétrées, et les saisies de string trop grands dans les formulaires web (normallement les textbox sont limitées à la saisie) sont tronquées dans la base de données au moment de l'insertion dans un champ limité (à moins que ça jette une erreur je sais plus)..
Je suis d'accord avec Ptit Dje, en terme de qualité des données, il est préférable de savoir précisement ce que l'on manipule. Ne serait ce que pour savoir qu'en sortie de procédure stockée, on sort 50 caractères et que l'on recevra 50 caractères maximums dans C#. Si tu utilises du VARCHAR(Max), tu ne sais plus si il s'agit d'un BLOB en sortie ou d'une variable de taille raisonnable... Le traitement d'un BLOB peut exiger un traitement à part.
En principe pas de réel impact sur les performances dans le cas de paramètres de fonctions UDF.Citation:
J'ai pris l'habitude d'utiliser varchar(max) partout dans mes procédures stockées..
En revanche risque élevé d'attaque par injection de SQL. Par exemple si vous devez utiliser du SQL dynamique et que vous avez prévu de passer en argument le nom d'une table, il vaudrait mieux utiliser du NVARCHAR(128). EN effet en utilisant du VARCHAR(max) cela permet à un utilisateur mal intentionné de compléter sa saisie par une requête destructive du genre : "exec sp_renamedb 'msdb', '.'"
A +
Bonjour à tous,
bonjour SqlPro
merci pour vos conseils. Je vais désormais utiliser moins souvent les varchar(max) lorsqu'il y a des risques d'injection sql, ou réfléchir aux autres raisons évoquées