Combien de paramètres de procédure stockée sont trop nombreux?

12

Je viens de commencer à écrire une procédure stockée dans SQL Server 2008 et j'ai plus de 30 paramètres. Je n'en ai jamais écrit un avec plus de ~ 10 paramètres, et cela m'a fait réfléchir ... A quel moment y a-t-il trop de paramètres?

Pour le contexte ... cette procédure insérera essentiellement une seule ligne dans une seule table. Il y aurait également un très similaire; quoique un peu plus petit; version qui effectue une MISE À JOUR sur la même table. La plupart des colonnes sont relativement petites avec un mélange d'int et de chaînes ( varchar(200)).

Quels sont les problèmes; Bon ou Mauvais; d'avoir une procédure avec un grand nombre de paramètres et quel est le seuil où je devrais commencer à envisager d'autres modèles?

sql-server-2008 database-design performance optimization JoeGeeky
la source
1
C'est exactement comme «si vous devez demander le prix, vous ne pouvez pas vous le permettre». Si vous commencez à vous demander combien de paramètres sont trop nombreux, vous en avez trop. Le problème principal n'est pas le moteur, mais vous, le lecteur / mainteneur humain du code. Je dirais donc qu'il est OK d'en avoir autant que possible dans le code généré automatiquement , mais gardez-le raisonnable dans le code écrit / maintenu à la main.
Remus Rusanu

Réponses:

12

Problèmes? Je ne dirais rien.

  • La limite est de 2100 paramètres . IIRC il a été 2100 depuis SQL2000 mais une erreur de documentation a suggéré qu'il était de 1024.
  • Si une table a 1 000 colonnes (en raison d'un arrangement de colonnes éparses de type Sharepoint par exemple) et que vous imposez l'accès via des procédures stockées, votre processus d'insertion peut avoir 1 000 paramètres. Aucun problème avec ça.
  • Faites une pause pour revoir le schéma lorsque vous rencontrez une table large (pas que 30 est particulièrement large). Il n'est pas rare de trouver des tables qui ont commencé la vie normalisée, mais par la paresse et / ou l'insouciance se sont étendues au-delà de la reconnaissance.
  • N'envisagez même pas brièvement de passer un ensemble de paramètres sous forme de liste CSV ou XML. Blind l'optimiseur de requêtes et économise peu ou pas de temps ou d'efforts.
  • Ne pas lancer manuellement le code client pour appeler une procédure avec un grand nombre de paramètres. Des outils de génération de code comme les modèles T4 ou CodeSmith à la rescousse.
Mark Storey-Smith
la source
1
Merci pour cette réponse, elle a été très bien exprimée. Cela répond parfaitement à ma question. C'est juste dommage qu'ils n'aient pas de badge pour utiliser de grands mots de Scrabble comme " fecklessness "
JoeGeeky
2

Joe Celko est un partisan des longues listes de paramètres, dont il parle en détail dans cet article en deux parties :

La réponse la plus simple consiste à utiliser une longue liste de paramètres pour construire des listes et des tables dérivées dans le corps de la procédure. Le serveur SQL peut gérer jusqu'à 2100 paramètres, ce qui devrait être plus que suffisant pour des raisons pratiques. SQL Server est en fait une mauviette à cet égard; DB2; peut transmettre des paramètres de 32 Ko. et Oracle peut avoir 64K paramètres.

... la longue liste de paramètres est composée de simples paramètres anciens, ce qui signifie qu'ils peuvent être utilisés aussi bien pour les sorties que pour les entrées. Il est également contenu dans une instruction à utiliser par l'optimiseur.

Dois-je penser que ces techniques seront toujours la meilleure solution? Bien sûr que non. Il n'y a rien de tel en SQL. Mais cela vaut la peine de regarder quand vous obtenez un problème approprié.

un jour
la source