Un paramètre de procédure stockée à valeurs multiples est-il simplement une mauvaise pratique?

J'ai l'aversion étrange de passer de multiples paramètres d'ID à une seule procédure stockée. Par exemple, cela se sent mal:Un paramètre de procédure stockée à valeurs multiples est-il simplement une mauvaise pratique?

GetMyObject (ListofIDs, OtherParam1, OtherParam2, ...)

Je comprends comment le faire (correctement si je dois) .. mais je ne me sens pas comme je devrait le faire. J'ai l'impression que cela va à l'encontre du but d'une procédure/sous-routine stockée "get item". Je pense que je devrais construire mes SP pour supporter les paramètres de filtre appropriés. Si mon interlocuteur a une liste d'ID, ne devrait-il pas appeler le sp autant de fois?

Aide?

Source

2010-07-20 deLux_247

Si un appelant a régulièrement besoin d'un tas d'objets et qu'il a un tas d'identifiants, je ne les forcerais pas à appeler plusieurs fois la même procédure. Je ne suis pas d'accord avec GetItem (...) renvoyant plusieurs éléments, mais aucun problème avec GetItems (...) le faisant. Les appels de base de données sont chers. – seanb

Une routine "get item by ID" ne doit jamais renvoyer plus d'un objet, car cela n'a absolument aucun sens linguistique.

Une routine "Obtenir des éléments par ID"? Bien sûr, si vous avez un cas d'utilisation décent pour cela et il sera utilisé assez souvent. Mais la plupart du temps, oui, au lieu d'une routine retournant plusieurs éléments par ID, vous voulez une routine qui retourne des éléments basés sur des paramètres de filtrage appropriés à l'application (par exemple: "donnez-moi toutes les transactions du 8 janvier pour plus de 10 $). "). Par ailleurs, parfois, une plage d'identifiants (par exemple tout ce qui se trouve entre 5 et 10) est un ensemble de filtres parfaitement valide! Par ailleurs, il ne s'agit pas forcément d'un problème MySQL ou SQL en général. Presque n'importe quel type de jeu de données interrogeant l'API dans n'importe quelle langue présentera ces mêmes questions de conception, et leurs réponses seront généralement très similaires.

Source

2010-07-20 02:16:42

Je suppose que c'est une façon intéressante d'y penser. Pourquoi une plage d'ID ne peut-elle pas être un ensemble de filtres? Le problème que je vois à maintes reprises est qu'une application va vouloir tous les éléments (pour une liste d'ID) dans un seul appel pour des raisons de "performance". Ainsi, au lieu de faire 16 appels, ils voudront faire un appel avec 16 identifiants. –

@ deLux_247: Si l'application a besoin d'un tel appel, donnez-lui. Ce n'est pas un choix déraisonnable pour certains cas d'utilisation. Mais je regarderais attentivement _why_ l'application en a besoin - d'où vient-elle les ID? Si elles proviennent de la base de données en premier lieu, pourquoi n'a-t-elle pas simplement demandé les données dont elle avait besoin alors? Est-ce qu'il y aura vraiment autant d'identifiants? Si le cas d'utilisation est seulement deux ou trois à la fois, par exemple, je ne vois pas pourquoi il ne peut pas l'appeler une seule fois pour chaque ID, sauf si votre infrastructure est sévèrement surchargée. –

Un paramètre de procédure stockée à valeurs multiples est-il simplement une mauvaise pratique?

Répondre

Questions connexes