Pasar argumentos variables a un SP

03/01/2005 - 14:12 por Leonardo Azpurua | Informe spam
Hola.

Si uno ve la sintaxis de sp_executesql, descubre que es posible pasar un
número variable de argumentos a "algunos" SP de SQL Server.

Acabo de leer detalladamente la descripcion de CREATE PROCEDURE, y no
describe ese mecanismo de ningun modo.

La implementacion de sp_executesql está oculta (definida como "Server
Internal").

Entonces: es posible de alguna manera más o menos esotérica pasar un numero
de argumentos variable a un SP?

Salud!

Preguntas similare

Leer las respuestas

#11 Carlos Sacristán
03/01/2005 - 17:12 | Informe spam
Leonardo, hacía referencia a este artículo porque creo que trata este
tema de forma bastante extensa y con datos sobre los que basarse para poder
desechar opciones. Yo personalmente creo que pasar el xml (al igual que hace
Rubén en su artículo) para implementar parámetros variables es lo que da
mejor rendimiento y sobre todo flexibilidad, así que olvidaría lo de usar
CHARINDEX de una forma u otra...


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Leonardo Azpurua" <l e o n a r d o (arroba) m v p s (punto) o r g> escribió
en el mensaje news:O#

"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:
> Leonardo, echa un vistazo a este artículo:
> http://www.sommarskog.se/arrays-in-sql.html

Hola, Carlos:

Creo que al final voy a investigar un poco como hacerlo con XML.

Pero hay que ver lo que dice la gente. En el articulo que refieres, se
describen varios métodos, que el autor divide en "los buenos" (The good
ones) y "los malos" (The ones to stay away from).

El primero de los buenos es "el metodo iterativo" y el último de los
malos son:

"Los métodos verdaderamente lentos: métodos que utilizan
charindex, patindex o LIKE. Estas soluciones son simplemente
increiblemente lentas incluso con conjuntos de entrada pequeños."

De manera que el primer metodo recomendado es "el metodo iterativo".

Pero vamos a la implementacion del metodo iterativo, y nos encontramos
con:

SET @pos = charindex(' ', @tmpstr)
WHILE @pos > 0
BEGIN
SET @str = substring(@tmpstr, 1, @pos - 1)
INSERT @tbl (number) VALUES(convert(int, @str))
SET @tmpstr = ltrim(substring(@tmpstr, @pos + 1, len(@tmpstr)))
SET @pos = charindex(' ', @tmpstr)
END

es decir, una implementación basada en CHARINDEX. ¿Pero esto no era
increiblemente lento, incluso con conjuntos de entrada pequeños?

¿Hay diferencias de performance entre utilizar CHARINDEX en un SP o
utilizarlo en una UDF?

Salud!


Respuesta Responder a este mensaje
#12 Leonardo Azpurua
03/01/2005 - 19:57 | Informe spam
"Carlos Sacristán" <csacristanARROBAmvpsPUNTOorg> escribió en el mensaje
news:
Leonardo, hacía referencia a este artículo porque creo que trata este
tema de forma bastante extensa y con datos sobre los que basarse para
poder
desechar opciones. Yo personalmente creo que pasar el xml (al igual que
hace
Rubén en su artículo) para implementar parámetros variables es lo que da
mejor rendimiento y sobre todo flexibilidad, así que olvidaría lo de usar
CHARINDEX de una forma u otra...



Hola, Carlos:

Hasta ahora me he manejado con SPs relativamente simples, haciendo "parseo"
de listas de numeros y esas cosas utilizando justamente CHARINDEX. El
articulo tiene su valor, en la medida en que ilustra una serie de tecnicas y
de alternativas para lograr el fin que describe (la simulación de
Arreglos -o el manejo de listas de datos- en Transact SQL). De repente me
enerva un poco leer que lo que hago es "poco recomendable" y luego encontrar
veinte lineas mas abajo que esa practica "poco recomendable" es la manera
"recomendada" de haer las cosas.

Quería saber si había alguna manera "simple" e inmediata de realizar
operaciones mas complejas (es un sistema de reservaciones, donde tengo que
pasar Tramos -en cantidad variable- y pasajeros -en cantidades tambien
variables, que pueden ir de uno a varios cientos.

La opción XML es, definitivamente, la mas adecuada para lo que necesito.

Pero más que reprochar ni siquiera levemente tu referencia, mi observación
fue para llamar la atención sobre la incongruencia de mucha de la literatura
que consultamos y encontramos "por ahi". Nuestro oficio y nuestra práctica
están cada vez más dominados por "buzzwords" (cosas tan triviales, evidentes
y evitables como la inyección de código, por ejemplo, están tomando la
dimensión de categorías fundamentales de diseño), y cada vez es mas
frecuente que nuestro pensamiento "repita" esos términos sin significados y
esos conceptos falsos (como las canciones de los loros) con consecuencias
como las que aparecen en ese articulo.

Pero nada que ver contigo, eso que describo :-)

Salud!
email Siga el debate Respuesta Responder a este mensaje
Ads by Google
Help Hacer una pregunta AnteriorRespuesta Tengo una respuesta
Search Busqueda sugerida