LinQ y actualizacion a SQL Server

Hola Jose ( Por cierto, este hilo está lleno de tocayos ;-) )

Bueno, eso confirma lo que le estoy explicando a Jose Luis que no hay que
preocuparse por el uso del sp_executesql. Yo sí me preocuparía por el
otro tema del update y cuando Linq manda codigo innecesario o redundante.

Jose TH


"Jose Antonio" escribió en el mensaje
news:

Yo he comprobado practicamente la diferencia entre ejecutar una sentencia
con sp_excutesql con parametros:

Ejecutando la misma sentencia con sp_executesql con diferentes valores de
parametros sucesivamente es bastante mas eficiente que enviar sentencias
que hacen lo mismo sin parametros desde el cliente.


"principiante" escribió en el mensaje de noticias
news:

>

Quizas la razon sea que para forzar a que sean parametrizadas
necesariamente tengan que armarse con sp_executesql. Ya eso seria una
explicacion pero eso tambien las haria menos eficientes en llamadas
frecuentes porque tengo entendido que con sp_executesql nunca se
guardan las rutas de ejecucion.

Una precisión.
Con el comando EXEC se daba eso que dices. Pero el Sp_ExecuteSQL se
creó precisamente para hacer mas eficientes las llamadas consecutivas
usando SQL dinámico cuando lo único que se haya variado en el comando
sean los valores de los parámetros. Si eso ocurre, ciertamente sí se
guardan los planes de ejecución por tanto no hay que preocuparse por la
eficiencia en este caso ya que para esos fines (solo diferencia en los
valores de los parametros) es prácticamente igual que haber armado la
cadena en la aplicación o tener un SP personalizado.

Ahora bien, si quieres un plan de ejecución siempre precompilado pues
entonces créate un store procedure pero no te sorprenda que al postear
una llamada desde la aplicación también se convierta a otra llamada
intermedia al Sp_ExecuteSQL. Sería normal en ese caso.


Jose TH

>

Quizas la razon sea que para forzar a que sean parametrizadas
necesariamente tengan que armarse con sp_executesql. Ya eso seria una
explicacion pero eso tambien las haria menos eficientes en llamadas
frecuentes porque tengo entendido que con sp_executesql nunca se guardan
las rutas de ejecucion.

Una precisión.
Con el comando EXEC se daba eso que dices. Pero el Sp_ExecuteSQL se creó
precisamente para hacer mas eficientes las llamadas consecutivas usando
SQL dinámico cuando lo único que se haya variado en el comando sean los
valores de los parámetros. Si eso ocurre, ciertamente sí se guardan los
planes de ejecución por tanto no hay que preocuparse por la eficiencia en
este caso ya que para esos fines (solo diferencia en los valores de los
parametros) es prácticamente igual que haber armado la cadena en la
aplicación o tener un SP personalizado.

Ahora bien, si quieres un plan de ejecución siempre precompilado pues
entonces créate un store procedure pero no te sorprenda que al postear una
llamada desde la aplicación también se convierta a otra llamada intermedia
al Sp_ExecuteSQL. Sería normal en ese caso.


Jose TH

Habra que ver otras opiniones más versadas pero siempre he tenido mis
dudas con la eficiencia de los queries que auto-genere Linq.

Ver este artículo relacionado:

http://blogs.solidq.com/ES/dseara/L...t.aspx?ID2



José TH



"Jose Luis" <x> wrote in message
news:%

Disculpen las preguntas reiteradas sobre LinQ en este foro pero es que
estado buscando otro newsgroup en español y no lo he encontrado.

Empece a hacer pruebas del linq de Orcas beta2 con SQL Server 2000
leyendo una tablita y actualizando una columna de tres columnas, siendo
la primera columna su clave primaria. Me la lee y actualiza muy bien
pero la inquietud es que en el SQL Profiler (herramienta para visualizar
los comandos que 'recibe' el servidor) veo que los comandos que recibe
desde LinQ son a traves del procedimiento del servidor "sp_executesql",
es decir SQL dinamico!.

En SQL Server siempre se nos dice que evitemos el SQL dinamico por su
ineficiencia e inseguridad. La pregunta es si LinQ siempre ejecutará sql
dinámico hacia el servidor SQL o hay alguna manera de configurarlo para
que no postee sql dinámico sino instrucciones directas?


La otra cosa extraña que vi fue a pesar de la tablita tener su clave
primaria (campo 'estado'), un update (SubmitChanges) de una fila para
actualizar el campo 'nombre' me puso en el WHERE del Update una
comparacion para todos los campos de la tabla, cuando solo bastaba con
preguntar por la clave primaria.

Me podrian explicar al respecto?


Jose Luis

Hola todos,

Buscando en la web me tope que este que si es que lo comprendi bien la
verdad que es preocupante en cuanto a rendimiento.

http://west-wind.com/WebLog/posts/136325.aspx


RS


"principiante" wrote in message
news:

Habra que ver otras opiniones más versadas pero siempre he tenido mis
dudas con la eficiencia de los queries que auto-genere Linq.

Ver este artículo relacionado:

http://blogs.solidq.com/ES/dseara/L...t.aspx?ID2



José TH



"Jose Luis" <x> wrote in message
news:%

Disculpen las preguntas reiteradas sobre LinQ en este foro pero es que
estado buscando otro newsgroup en español y no lo he encontrado.

Empece a hacer pruebas del linq de Orcas beta2 con SQL Server 2000
leyendo una tablita y actualizando una columna de tres columnas, siendo
la primera columna su clave primaria. Me la lee y actualiza muy bien
pero la inquietud es que en el SQL Profiler (herramienta para visualizar
los comandos que 'recibe' el servidor) veo que los comandos que recibe
desde LinQ son a traves del procedimiento del servidor "sp_executesql",
es decir SQL dinamico!.

En SQL Server siempre se nos dice que evitemos el SQL dinamico por su
ineficiencia e inseguridad. La pregunta es si LinQ siempre ejecutará
sql dinámico hacia el servidor SQL o hay alguna manera de configurarlo
para que no postee sql dinámico sino instrucciones directas?


La otra cosa extraña que vi fue a pesar de la tablita tener su clave
primaria (campo 'estado'), un update (SubmitChanges) de una fila para
actualizar el campo 'nombre' me puso en el WHERE del Update una
comparacion para todos los campos de la tabla, cuando solo bastaba con
preguntar por la clave primaria.

Me podrian explicar al respecto?


Jose Luis

El autor está describiendo lo que podría pasarle a alguien q utilice LINQ
to SQL sin conocer sus fundamentos. Él mismo indica la vía correcta de
actuar al final del post.

Creo q eso podría pasarle a cualquiera con cualquier nueva tecnología...