LINQ ?

On Mon, 14 Apr 2008 15:33:37 +0200, "Jesús López"
wrote:

El problema Alfredo es que muchas veces no da igual como escribas la
sentencia SQL. En ciertos casos puedes obtener un aumento de rendimiento
espectacular escribiéndolas de otra forma.

Si, los optimizadores de los SGBD que han por ahí no suelen ser muy
buenos.

Si usas LINQ to SQL o Entity
Framework, pierdes el control de las sentencias SQL que se envían al
servidor. Al perder tal control, también pierdes capacidad de optimización.

Tampoco pierdes tanto el control por que conociendo un poco LINQ
puedes "adivinar" que código SQL va a generar y escribir la sentencia
LINQ de forma que genere código "eficiente". Normalmente es bastante
fácil adivinarlo por que la sintaxis de LINQ en la mayoría de los
casos es solo una mala copia de la de SQL.

A mi me parece mucho más serio el problema de que en algunos casos
LINQ hace que se lancen muchísimas más consultas de las necesarias.

Yo estoy convencido de que si el rendimiento es un factor crítico en tu
aplicación, entonces no es buena idea usar LINQ to SQL ni Entity Framework.

Bueno, en mi sector el rendimiento casi nunca es un factor de primera
importancia.

Para mi el factor crítico es el coste de desarrollo y mantenimento, y
para eso LINQ podría ser una gran ayuda si estuviese bien hecho.

Si en vez de usar LINQ to SQL o Entity Framework, o sentencias SQL
incrustadas en el código de la aplicación cliente, se usan procedimientos
almacenados, entonces tu aplicación es aún más optimizable, ya que un DBA
puede optimizar aún más la aplicación incluso estando ya en producción, dado
que el DBA puede cambiar el código de los procedimientos almacenados.

Pero en la mayoría de los casos es mucho mejor usar vistas para esto.

Con LINQ to SQL o Entity Framework o cualquier otra herramienta que genere
SQL en tiempo de ejecución, tienes menos posibilidades de optimización
incluso en la fase de desarrollo, ya te tienes que aguantar con el código
SQL que generan estas herramientas.

Depende, por que podrían generar un código SQL más eficiente que el
que escribe la mayoría de los programadores.

Con código SQL incrustado en la aplicación cliente, puedes optimizarlo en
tiempo de desarrollo. Pero las condiciones cambian mucho en producción,
incluso la misma aplicación instalada en distintos clientes. Y se necesita
poder optimizar la aplicación ya en producción. Si usas procedimientos
almacenados entonces esto se puede hacer, si no, es mucho más difícil
hacerlo.

Usando vistas puedes conseguir lo mismo en optmización que con
procedimientos almacenados con la ventaja de que las vistas son tablas
y son fácilmente actualizables con databindings. Con vistas el
desarrollo sería más rápido.


Saludos
Alfredo

Alfredo,

Las vistas no resuelven en absoluto los problemas de rendimiento, es más,
mal utilizadas lo empeoran. Yo he visto aplicaciones en las que hay vistas
sobre vistas con un nivel de anidamiento mucho mayor de lo deseable, que al
final "expandida" suponen 12 joins cuando la consulta podría resolverse con
4.

Es cierto que el código SQL generado por LINQ es mejor que el código SQL
escrito por algunos programadores novatos, pero es peor que el código SQL
escrito por DBA's y desarrolladores expertos en SQL, por eso digo que usando
procedimientos almacenados es posible optimizar en mayor medida una
aplicación incluso después de estar en producción.

A nuestra empresa la contratan muchas veces para optimizar aplicaciones que
ya están en producción y que tienen un rendimiento pobre. Muchas veces no
tenemos acceso al código fuente de las aplicaciones, sin embargo vemos los
defectos del código SQL que envían las aplicaciones a SQL Server por medio
del SQL Server Profiler. Muchas veces poca cosa podemos hacer precisamente
porque no podemos modificar el código SQL que envían las aplicaciones y
sabemos que si lo pudiéramos cambiar, aumentaríamos espectacularmente el
rendimiento. Si la aplicación usara procedimientos almacenados nosotros la
podríamos optimizar mucho más de lo que lo hacemos.


En cuanto a desarrollo rápido, mantenibilidad, etc, lo cierto es que hay
pocas herramientas RAD que basen su acceso a datos en procedimientos
almacenados. En realidad yo solo conozco una, precisamente la nuestra que
presentamos el día 21 en Madrid y el día 22 en Barcelona y se llama
SolidRAD:


http://msevents.microsoft.com/CUI/E...px?EventID32375244&Culture=es-ES





http://msevents.microsoft.com/CUI/E...px?EventID32375246&Culture=es-ES



Saludos:



Jesús López

www.solidq.com





"Alfredo Novoa" escribió en el mensaje
news:

On Mon, 14 Apr 2008 15:33:37 +0200, "Jesús López"
wrote:

El problema Alfredo es que muchas veces no da igual como escribas la
sentencia SQL. En ciertos casos puedes obtener un aumento de rendimiento
espectacular escribiéndolas de otra forma.

Si, los optimizadores de los SGBD que han por ahí no suelen ser muy
buenos.

Si usas LINQ to SQL o Entity
Framework, pierdes el control de las sentencias SQL que se envían al
servidor. Al perder tal control, también pierdes capacidad de
optimización.

Tampoco pierdes tanto el control por que conociendo un poco LINQ
puedes "adivinar" que código SQL va a generar y escribir la sentencia
LINQ de forma que genere código "eficiente". Normalmente es bastante
fácil adivinarlo por que la sintaxis de LINQ en la mayoría de los
casos es solo una mala copia de la de SQL.

A mi me parece mucho más serio el problema de que en algunos casos
LINQ hace que se lancen muchísimas más consultas de las necesarias.

Yo estoy convencido de que si el rendimiento es un factor crítico en tu
aplicación, entonces no es buena idea usar LINQ to SQL ni Entity
Framework.

Bueno, en mi sector el rendimiento casi nunca es un factor de primera
importancia.

Para mi el factor crítico es el coste de desarrollo y mantenimento, y
para eso LINQ podría ser una gran ayuda si estuviese bien hecho.

Si en vez de usar LINQ to SQL o Entity Framework, o sentencias SQL
incrustadas en el código de la aplicación cliente, se usan procedimientos
almacenados, entonces tu aplicación es aún más optimizable, ya que un DBA
puede optimizar aún más la aplicación incluso estando ya en producción,
dado
que el DBA puede cambiar el código de los procedimientos almacenados.

Pero en la mayoría de los casos es mucho mejor usar vistas para esto.

Con LINQ to SQL o Entity Framework o cualquier otra herramienta que genere
SQL en tiempo de ejecución, tienes menos posibilidades de optimización
incluso en la fase de desarrollo, ya te tienes que aguantar con el código
SQL que generan estas herramientas.

Depende, por que podrían generar un código SQL más eficiente que el
que escribe la mayoría de los programadores.

Con código SQL incrustado en la aplicación cliente, puedes optimizarlo en
tiempo de desarrollo. Pero las condiciones cambian mucho en producción,
incluso la misma aplicación instalada en distintos clientes. Y se necesita
poder optimizar la aplicación ya en producción. Si usas procedimientos
almacenados entonces esto se puede hacer, si no, es mucho más difícil
hacerlo.

Usando vistas puedes conseguir lo mismo en optmización que con
procedimientos almacenados con la ventaja de que las vistas son tablas
y son fácilmente actualizables con databindings. Con vistas el
desarrollo sería más rápido.


Saludos
Alfredo

On 14 apr, 18:47, "Jesús López"
wrote:

Alfredo,

Las vistas no resuelven en absoluto los problemas de rendimiento, es más,
mal utilizadas lo empeoran. Yo he visto aplicaciones en las que hay vistas
sobre vistas con un nivel de anidamiento mucho mayor de lo deseable, que al
final "expandida" suponen 12 joins cuando la consulta podría resolverse con
4.

Y los procedimientos almacenados 'mal utilizados' resuelven el
problema
en vez de empeorarlo?

Habrá que comparar vistas 'bien utilizadas' con sp's 'bien
utilizados'.
digo yo.

Saludos,
Carlos

On Mon, 14 Apr 2008 18:47:42 +0200, "Jesús López"
wrote:

Las vistas no resuelven en absoluto los problemas de rendimiento, es más,
mal utilizadas lo empeoran.

No debes de haberme entendido, por que sino no me lo explico.

A ver, lo voy a intentar otra vez.

Me imagino que tu te refieres a que los programadores de aplicaciones
en lugar de incrustar sentencias SQL complejas en el código de la
aplicación simplemente llamen a procedimientos almacenados que
devuelvan tablas.

Pues con vistas se puede hacer exactamente igual, en lugar de ejecutar
una consulta compleja ejecutas una sencilla que tire de una vista, y
entonces el DBA puede romperse los cuernos para optimizar la vista
aunque la aplicación ya esté en producción (por ejemplo
"materializando" la vista).

Y la vista tiene la ventaja de que es mucho más versatil que el
procedimiento almacenado por que además de poder actualizarla hay
muchas consultas sencillas que van a tener prácticamente el mismo
rendimiento por que prácticamente solo hay una forma de hacerlas :-),
y así evitas crear muchos procedimientos almacenados muy parecidos con
combinaciones del patrón "select * from vista where condición".

Yo he visto aplicaciones en las que hay vistas
sobre vistas con un nivel de anidamiento mucho mayor de lo deseable, que al
final "expandida" suponen 12 joins cuando la consulta podría resolverse con
4.

Aqui estoy de acuerdo con Carlos.

Es cierto que el código SQL generado por LINQ es mejor que el código SQL
escrito por algunos programadores novatos, pero es peor que el código SQL
escrito por DBA's y desarrolladores expertos en SQL,

No me estaba refiriendo a LINQ, sino a una hipotética herramienta
mucho más sofisticada.

En realidad esto es una repetición de la vieja discusión ensamblador
vs lenguajes de alto nivel, y ya se sabe quien gana a la larga :-)

Desde el momento en que usas SQL Server estás perdiendo control sobre
como se hacen las consultas, así que si el rendimiento es crucial
entonces también te podría decir que no uses SQL Server y que te hagas
un procesador de consultas en ensamblador para controlar el proceso de
la consulta de arriba a abajo.

Es evidente que hay que hacer un análisis coste beneficio entre el
coste ponderado del posible menor rendimiento y el beneficio del
ahorro de tiempo de desarrollo y mantenimiento.

por eso digo que usando
procedimientos almacenados es posible optimizar en mayor medida una
aplicación incluso después de estar en producción.

Y yo espero que ya esté claro que con vistas es igual.


Saludos
Alfredo

On Mon, 14 Apr 2008 22:29:56 +0200, Alfredo Novoa
wrote:

y así evitas crear muchos procedimientos almacenados muy parecidos con
combinaciones del patrón "select * from vista where condición".

Mejor dicho: select a,b, ... from vista where condición

Desde el momento en que usas SQL Server estás perdiendo control sobre
como se hacen las consultas, así que si el rendimiento es crucial
entonces también te podría decir que no uses SQL Server y que te hagas
un procesador de consultas en ensamblador para controlar el proceso de
la consulta de arriba a abajo.

Aqui me refiero a programar las consultas específicas de la aplicación
en ensamblador, como se hacía en los 50, por que no hay nada que
supere el rendimiento del código en ensamblador de un programador
experto.


Saludos
Alfredo