Optiimización SQL dinámico.

10/12/2008 - 18:06 por Pedro J. Reguera | Informe spam
Hola,
Tengo una aplicación que construye dinámicamente una sentencia SQL.
La pregunta es:
¿qué es más eficiente, desde asp.net construir el SQL y traerme los datos en
un datareader ejecutando la sentencia SQL o...
pasarle una cadena como un parámetro a un procedimiento almacenado para que
este ejecute la misma tipo "EXECUTE(@vstrSQL) y devuelva los datos para
poblar el datareader?.

Gracias y un saludo.
Pedro J.

Preguntas similare

Leer las respuestas

#6 Pedro J. Reguera
11/12/2008 - 12:29 | Informe spam
Ok, gracias a todos, ya me queda claro que usar el Datareader, de todas
formas explico un poco más de que se trata:
Hemos desarrollado un sistema para montar dinámicamente mantenimientos de
tablas de forma que una aplicación lee unas tablas definindas por nosotros
en la que declaramos la estructura de los formularios y tablas que en estos
se muestran y no tenemos que teclear código ninguno al realizar nuestras
aplicaciones para las operaciones "normales" (lease, búsquedas, orden por
distintos campos, altas, modificaciones, bajas, búsquedas en tablas
asociadas, etc.), es más, aunque está en asp.net no tenemos interfaz
"visual" de los formularios, todo se monta a partir de la definición que
hemos hecho en otras tablas. Para eso, como es lógico, tenemos que montar
consultas SQL dinámicas y debido a la complejidad y variedad de tablas los
parámetros no están "normalizados".

De nuevo un saludo al grupo.
Pedro J.


"Jose TH >>" escribió en el mensaje de noticias
news:
Hola,
Tengo una aplicación que construye dinámicamente una sentencia SQL.
La pregunta es:
¿qué es más eficiente, desde asp.net construir el SQL y traerme los datos
en un datareader ejecutando la sentencia SQL o...
pasarle una cadena como un parámetro a un procedimiento almacenado para
que este ejecute la misma tipo "EXECUTE(@vstrSQL) y devuelva los datos
para poblar el datareader?.




No sé si la idea de tu pregunta es sobre eficiencia en el servidor o en
cómo hacer la llamada en tu aplicación.
Desde tu aplicación, si no hay parámetros, con ese Execute() estarías
prácticamente suplantando lo que ya hace el datareader al ejecutarlo
(ExecuteReader). Si los hay, el datareader ya sabrá que debe usar
sp_ExecuteSQL para la llamada parametrizada. Por tanto, si te entendí
bien, deja que el datareader se encargue, que para eso está.
Si tienes dudas de lo que "manda" el datareader al servidor, usa el
Profiler de SQL Server para visualizarlo.
Si, como te dijo Alejandro, te interesa que se guarde el plan de
ejecución, trata de que la instrucción con su tipo y cantidad de
parámetros sea la misma siempre y que sólo cambien los valores de los
parámetros.







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