¿Cuántos parámetros de procedimientos almacenados son demasiados?

12

Acabo de comenzar a escribir un procedimiento almacenado en SQL Server 2008 y tengo más de 30 parámetros. Nunca he escrito uno con más de ~ 10 parámetros, y eso me hizo pensar ... ¿En qué punto hay demasiados parámetros?

Para el contexto ... este procedimiento esencialmente INSERTARÁ una sola fila en una sola tabla. También habría un muy similar; aunque algo más pequeño; versión que realiza una ACTUALIZACIÓN en la misma tabla. La mayoría de las columnas son relativamente pequeñas con una mezcla de int y strings ( varchar(200)).

¿Cuáles son los problemas? bueno o malo; a tener un procedimiento con una gran cantidad de parámetros y cuál es el umbral donde debería comenzar a considerar otros patrones?

— JoeGeeky
fuente

1

Es exactamente como "si tiene que preguntar el precio, no puede pagarlo". Si comienza a preguntarse cuántos parámetros son demasiados, tiene demasiados. El problema principal no es el motor, sino usted, el lector / mantenedor humano del código. Por lo tanto, diría que está bien tener la mayor cantidad posible en el código generado automáticamente , pero que sea razonable en el código escrito / mantenido.

— Remus Rusanu 01 de

12

¿Cuestiones? Yo diría que ninguno.

El límite es de 2100 parámetros . IIRC ha sido 2100 desde SQL2000 pero un error de documentación sugirió que era 1024.
Si una tabla tiene 1000 columnas (debido a una disposición de columnas dispersas de Sharepoint-esque , por ejemplo) y está exigiendo el acceso a través de procedimientos almacenados, su proceso de inserción puede tener 1000 parámetros. Nada de malo con eso.
Haga una pausa para revisar el esquema cuando encuentre una tabla ancha (no es que 30 sea particularmente ancho). No es raro encontrar tablas que comenzaron con una vida normalizada, pero a través de la pereza y / o la imprudencia se han expandido más allá del reconocimiento.
Ni siquiera considere pasar brevemente un conjunto de parámetros como una lista CSV o XML. Ciega el optimizador de consultas y ahorra poco o nada de tiempo o esfuerzo.
No arranque el código del cliente para llamar a un procedimiento con una gran cantidad de parámetros. Herramientas de generación de código como plantillas T4 o CodeSmith al rescate.

— Mark Storey-Smith
fuente

1

Gracias por esta respuesta, fue muy bien dicho. Esto responde a mi pregunta perfectamente. Es una lástima que no tienen una tarjeta de identificación para el uso de grandes palabras Scrabble como " irresponsabilidad "

— JoeGeeky

2

Joe Celko es un defensor de largas listas de parámetros, sobre las que escribe en detalle en este artículo de dos partes :

La respuesta más simple es usar una larga lista de parámetros para construir listas y tablas derivadas dentro del cuerpo del procedimiento. El servidor SQL puede manejar hasta 2100 parámetros, que deberían ser más que suficientes para fines prácticos. SQL Server es realmente un debilucho en este sentido; DB2; puede pasar parámetros de 32K. y Oracle puede tener 64K parámetros.

... la larga lista de parámetros se compone de parámetros antiguos simples, lo que significa que pueden usarse tanto para salidas como para entradas. También está contenido en una declaración para que el optimizador lo use.

¿Creo que estas técnicas siempre serán la mejor solución? Por supuesto no. No existe tal cosa en SQL. Pero vale la pena mirar cuando tiene un problema apropiado.

— un día cuando
fuente