La taille de varchar est-elle importante dans les tables temporaires?

16

Il y a un débat au travail de ma femme sur l'utilisation varchar(255)de tous les varcharchamps dans les tables temporaires des procédures stockées. Fondamentalement, un camp veut utiliser 255 car cela fonctionnera toujours même si la définition change, et l'autre camp veut s'en tenir à la taille dans les tableaux source pour des améliorations potentielles des performances.

Le camp de performance est-il correct? Y a-t-il d'autres implications? Ils utilisent SQL Server.

sql-server performance datatypes temporary-tables Brian Nickel
la source
Je dirais que vous n'avez peut-être pas besoin de tables temporaires en premier lieu. À quoi servent-ils? S'ils sont nécessaires, à quoi servent ces colonnes spécifiques? Sont-ils utilisés dans des jointures ou des comparaisons de toute nature? Y a-t-il des colonnes sous-jacentes nvarchar et non varchar?
Aaron Bertrand
@AaronBertrand Les tables temporaires sont là pour la modularité. Les données sont transformées et remplies un certain nombre de fois en fonction de règles métier qui peuvent changer. Je pense qu'il y en a aussi quelques uns MAX()dans le mix.
Brian Nickel

Réponses:

6

Selon la façon dont vous utilisez vos tables temporaires, vous pouvez rencontrer un problème de troncature des données.

Cet exemple est un peu artificiel, mais il illustre mon point. Exemple:

  1. La colonne de votre table utilisateur est varchar (50).
  2. Votre colonne de table temporaire est varchar (255).
  3. Vous avez un enregistrement avec 45 caractères dans cette colonne de votre table utilisateur.
  4. Dans votre procédure, vous concaténez «- pour la victoire» à la fin de cette colonne, avant de fusionner cette table temporaire dans votre table utilisateur.

La table temporaire accepterait volontiers la nouvelle valeur varchar avec une longueur de 59. Cependant, votre table utilisateur ne pouvait pas. Selon la façon dont vous gérez cela dans votre procédure, cela peut entraîner une troncature ou une erreur.

À moins que vous ne documentiez et teniez compte de ces problèmes, votre procédure pourrait s'exécuter de manière inattendue.

Personnellement, je ne pense pas qu'il y ait une réponse à cette question qui soit correcte 100% du temps. Cela dépend vraiment de la façon dont vous utilisez ces tables temporaires.

J'espère que cela t'aides

Matt M
la source
0

utilisation varchar(255)pour tous les varcharchamps des tables temporaires des procédures stockées.

Je pencherais pour l'utilisation de la longueur réelle du champ.

J'ai lu récemment que les tables temporaires MySQL (je suppose que SQL Server est similaire) allouent suffisamment de mémoire pour stocker la longueur maximale possible pour chaque varcharcolonne ... Une approche systématique pour allouer 200% à 500% de la mémoire requise pour les varcharchamps dans tous les procédures stockées semblent être un recours inutile aux ressources système. Si vous utilisez jamais une quantité importante de mémoire pour créer ces tables temporaires, vous pourriez alors réclamer inutilement la mémoire utilisée pour la mise en cache, créant plus de travail pour le serveur à un moment donné dans le futur, même après que les procédures de stockage soient terminées.

Edit: Voir la réponse de Bill Karwin: /programming/1962310/importance-of-varchar-length-in-mysql-table

Mat
la source
2
En supposant que SQL Server est similaire? Je ne voudrais pas ...
AK
Désolé, je me rends compte que ma réponse est incomplète. Ce que je veux dire, c'est que je me méfierais de la prudence (c'est-à-dire de ne pas apporter de changement qui pourrait avoir un effet négatif sur la performance) à moins que cette hypothèse ne soit établie comme étant erronée.
Matt