J'ai lu here que le nombre maximum de paramètres qui peuvent être transmis à une procédure stockée est 2100.Paramètres SQL Max
Je suis juste curieux de savoir quel genre de système nécessiterait un SP avec 2100 paramètres à passer, et ne pourrait-on pas diviser cela en plusieurs SP? Je pensais que peut-être un SP qui appelle plusieurs SP nécessiterait beaucoup de paramètres à passer, je ne peux pas imaginer écrire cette déclaration EXEC dégoûtant.
Si vous avez une procédure stockée en utilisant 2100 paramètres très probablement une sorte de problème de conception. Passer une liste CSV de valeurs dans un seul paramètre (et utiliser une fonction de division de table pour les transformer en lignes) ou utiliser un paramètre de table serait beaucoup plus simple que de gérer tous ces paramètres d'entrée.
+1: Ceci est l'un de ces "si vous avez à demander .." des questions –
C'était mes premières pensées quand j'ai lu ce fait. – Jim
j'ai eu une situation où je devais courir quelque chose de tout à fait comme ce qui suit:
SELECT
...
WHERE
ID IN (?,?,?,?...)
La liste des paramètres sélectionnée toutes les entités que l'utilisateur avait l'autorisation d'utiliser dans le système (il a été généré dynamiquement par un sous-jacent cadre). Il s'avère que le SGBD avait une limitation sur le nombre de paramètres à passer comme ça, et il était inférieur à 2100 (IIRC, c'était Oracle et le maximum était de 999 paramètres dans la liste IN). Ce serait un bon exemple d'une assez longue liste de paramètres pour quelque chose qui devait être une procédure stockée (nous avions plus de 999 et moins de 2100 paramètres à transmettre).
Je ne sais pas si l'application 999 contrainte au serveur SQL, mais il est certainement une situation où la liste serait utile ...
J'ai rencontré cette limite dans Oracle de 1000 paramètres par expression IN plus d'une fois. Curieusement, vous pouvez contourner ce problème en utilisant plus d'une condition IN: 'id IN (premier 1000 ids) OU id IN (next 1000 ids)'. –
Oui. C'était il y a longtemps, mais IIRC, c'est ce que nous avons fait à l'époque. –
il serait plus facile de transmettre une liste CSV de paramètres et de les diviser en lignes dans la procédure stockée où vous pouvez vous joindre à eux ou les utiliser autrement comme une table. –
La limite des paramètres de procédures est antérieure à la fois au type de données XML et aux paramètres de la table, de sorte qu'à cette époque, il n'y avait tout simplement pas d'alternative. Avoir 2100 paramètres sur une procédure ne signifie pas nécessairement qu'un humain l'a écrit ni qu'un humain l'appellera. Il est assez commun dans le code généré, comme le code créé par les outils et les frameworks, de repousser ces limites pour tout langage, puisque la maintenance et la refactorisation du code généré se produisent dans l'outil générateur, pas dans le code résultat.
Si vous avez déjà travaillé avec Microsoft CRM, vous disposez d'une expérience avec un système qui nécessiterait des procédures stockées avec ce nombre de paramètres pour une procédure stockée. –
Je n'ai pas. Je travaille seulement professionnellement depuis environ 2 ans. Donc, en apprenant plus sur la langue que j'utilise, je suis tombé sur ce fait intéressant. Et était juste une question curieuse. – Jim