LINQ ?

On Tue, 15 Apr 2008 13:04:42 +0200, "Jesús López"
wrote:

Vuelvo a repetir que las vistas no son una solución al problema del
rendimiento. Pero si insistes ¿por qué no me muestras un ejemplo de que la
vista acelere el rendimiento?.

Te acabo de poner uno. Si que resulta difícil explicarte esto que
viene en los primeros capítulos de cualquier buen libro de teoría de
bases de datos.

Por ejemplo yo tengo una vista que se llama "Pies" que "calcula" los
pies de los documentos (ofertas, pedidos, albaranes, facturas, etc).
La consulta de la vista tiene 73 lineas si la miras desde el
Management Studio. Las aplicaciones lanzan consultas muy sencillas
sobre esa vista para mostrar los pies de un grupo de documentos o de
un documento en particular, e incluso lanzan consultas que suman los
pies de varios albaranes para mostrar el pie de una factura formada
por varios albaranes. Estas consultas son tan sencillas que es
evidente que no se pueden optimizar más, y por lo tanto no tiene
sentido perder tiempo para encapsularlas más.

La primera versión de esa vista tenía un rendimiento aceptable pero no
demasiado bueno y la he optimizado sin tener que tocar para nada las
aplicaciones. En este caso no se usan vistas indizadas.

Antes de esta vista había un procedimiento almacenado que usaba
cursores y que era mucho menos versatil.

Imagina que la aplicación ya está en producción y que utiliza SQL
incrustado en la propia aplicación con la edición estándar de SQL Server,
crear una vista indexada no me sirve. Sin embargo, si esa consulta estuviera
en un procedimiento almacenado,

Macho, para eso imagínate que usas MySQL 2.0 y entonces tampoco te
sirve crear un procedimiento almacenado por que no se puede crear.

yo como DBA o como la persona que han
contratado para optimizar la aplicación podría modificar el procedimiento
almacenado para escribirla de esta otra manera:

SELECT lista de campos FROM Vista1 WITH(NOEXPAND) WHERE UnaCondicion

Esto es un caso muy particular cuando usas un producto específico
capado que tiene las vistas indizadas casi inoperativas.

Si usas SQL Server estandar y necesitas utilizar vistas indizadas de
forma intensiva, entonces te tienes que pasar a la versión empresarial
o a Oracle y pasar de la chapuza del NOEXPAND. Así que este ejemplo
tiene muy poco valor igual que los demás.

Lo que estoy intentando transmitir desde el principio, es que poniendo las
instrucciones SQL dentro de procedimientos almacenados haces que la
aplicación sea más optimizable puesto que puedes cambiar dicho código SQL
sin necesidad de tener acceso al código fuente de la aplicación y sin tener
que recompilarla y volverla a desplegar.

Y yo te estoy intentando transmitir que con vistas se puede hacer lo
mismo de una forma bastante más flexible y facilitandoles el trabajo a
los desarrolladores de aplicaciones cosa que es una de las
responsabilidades de un buen DBA.

Sin quieres puedo ponerte otro ejemplo de optimización. Supongamos que la
Tabla1 tiene un millon de registros con una clave primaria numérica entera
llamada ID. Y observamos en el SQL Server Profiler consultas así:

SELECT lista de campos FROM Tabla1 WHERE ID = '123345'

Otro ejemplo extraño que intenta explotar un defecto de diseño de SQL
Server. Esa consulta debería de devolver un error.

Es decir que el literal está entre comillas. Debido a como están definidas
las precedencias y las conversiones en SQL Server. SQL Server en vez de
convertir el literal a un entero convierte el ID a cadena de caracteres, y
entonces no usa el índice de la clave primaria para encontrar el registro,
en su lugar se lee el millon de registros.

Lo acabo de probar ahora mismo y el plan dice que si que usa el índice
cluster y que hace 'seek' en lugar de 'scan', y me salen exactamente
los mismos costes estimados.

Veamos un ejemplo más de optimización. Supongamos que tenemos una tabla
Tabla1 con algún que otro millón de registros, que tiene un campo Fecha de
tipo datetime, donde se almacena la fecha y la hora. Y vemos en el Profiler
consultas que sacan los registros de la tabla para un día determinado
haciendo algo como esto:

SELECT * FROM Tabla1 WHERE CONVERT(datetime, FLOOR(CONVERT( float, Fecha)))
= '20080408'

Macho, todos estos ejemplos son muy chorras. Yo presupongo que trabajo
con programadores que no son simios y que no intentan bajar el
rendimiento a propósito.

Yo uso las vistas para "encapsular" consultas mucho más complejas. Si
un programador no sabe hacer un select ... from where ...
correctamente entonces no dura mucho en mi empresa.

Los procedimientos almacenados no sólo tienen la ventaja de hacer la
aplicación más optimizable, tienen otras como por ejemplo la encapsulación o
la posibilidad de tener una mayor granularidad en la autorización. Los
procedimientos almacenados sirven de fachada o de interfaz con la base de
datos.

El problema es que estás creando una fachada de bajo nivel y muy
rígida por encima de una fachada mucho más flexible y de mucho más
alto nivel, y aun encima estás trabajando bastante para empeorar las
cosas.

Todos estamos acostubrados a ver librerías de clases que exponen las
clases públicas, y de éstas los métodos públicos, pero no nos dejan usar las
clases internas ni su métodos ni propiedades privados. ¿Por qué con SQL
Server tiene que ser diferente?

Por que se utiliza un modelo computacional muy superior y no tiene
sentido trabajar para degradarlo al nivel de unas bibliotecas de
clases.

¿No es una buena idea que en nuestras
aplicaciones cada capa tenga su propia fachada e interfaz al exterior y
oculte sus interiorirdades y su implementación?

No estamos hablando de las aplicaciones estamos hablando de la base de
datos y las vistas son una parte fundamental para la creación del
nivel externo de una base de datos como puedes ver en los primeros
capítulos de cualquier libro de introducción a la materia.

Los DBA's tienen otra opinión acerca de los procedimientos almacenados. La
mayoría de los DBA's preferirían que las aplicaciones accedieran por medio
de procedimientos almacenados.

Yo creo que esto puede venir de que la mayoría de los DBAs se forman
en cursillos de muy baja calidad y no suelen entender ni medio bien el
Modelo Relacional. Yo incluso he llegado a conocer a DBAs que dejaban
la integridad de los datos (excepto la más básica de las PK y las FK)
en manos de las aplicaciones :-O

A ellos les dan la responsabilidad de que el
sistema de base de datos funcione bien y sea eficiente. Si hay problemas de
eficiencia al primero que recurren es al DBA, y si la aplicación cliente usa
procedimientos almacenados, al DBA le estamos facilitando su trabajo, si no,
es casi como que tiene las manos atadas.

Pero si es justo al revés, el DBA debe de crear una "fachada" como tu
la llamas para facilitarles las cosas a los programadores de
aplicaciones.

Si el nivel externo de la base de datos está compuesto
fundamentalmente por tablas (las vistas son tablas) como dicen los
principios más elementales de la teoría, entonces eso le facilitará
mucho las cosas a los desarrolladores.

Todo eso que dices de programar en ensamblador, yo diría que está fuera de
contexto o más que es una exageración. Aquí estamos teniendo una discusión
técnica de las ventajas e inconvenientes de usar procedimientos almacenados,
vistas, ORM's, LINQ to SQL etc.

No es una exageración es la eterna discusión de alto nivel contra bajo
nivel que se repite una y otra vez a lo largo de las décadas. Tiene
bastante poco suspense quien va a ganar al final.

No tendría sentido ponerse a programar un sistema de base de datos desde
cero en ensamblador. Entre otras cosas porque saldría carísmo, y se tardaría
muchísimo y ¿quien te iba a asegurar que fuera a ser más eficiente que SQL
Server?

Ahí es a donde quería yo llegar. Cuando algo como LINQ funcione bien
no tendrá sentido seguir utilizando "frameworks" primitivos entre
otras cosas por que saldría carísimo y se tardaría muchísimo y quien
te iba a asegurar que fuese más eficiente que LINQ 2034 :-)

Este tipo de optimizaciones de las que he puesto algunos ejemplos, sí que
están a nuestro alcance. Programadores expertos en SQL Server los hay, y no
necesitan meses para localizar las consultas más pesadas y optimizarlas,
muchas veces se trata de cosas tan tontas como los ejemplos que he puesto.
Otra veces no, por supuesto. Hace poco me encontré con un procedimiento
almacenado complicadísimo que usaba procesamiento registro a registro con
cientos de líneas de código. Tardaba 35 segundos en ejecutarse. Me llevó
varios días entenderlo y reescribirlo, pero conseguí reducir su tiempo a 1,5
segundos. Si el código hubiera estado en la aplicación cliente, no hubiera
podido hacer prácticamente nada, ya que no tenía acceso al código fuente que
era de una aplicación de un tercero.

Hombre, en lo que si que estoy completamente de acuerdo es en que es
mucho mejor un procedimiento almacenado que un procedimiento que
calcule datos en las aplicaciones.


Saludos

On Tue, 15 Apr 2008 13:18:36 +0200, "Jesús López"
wrote:

Lo que estoy intentando decir es que el uso de procedimientos almacenados
hace que la aplicación sea más optimizable. Para ello lo que puedes hacer es
cambiar el código de los procedimientos almacenados para aumentar el
rendimiento y sin afectar a la aplicación cliente ya estando en producción,
sin tener acceso al código fuente, sin tener que recompilar la aplicación ni
volverla a desplegar.

Pues lo que yo estoy intentando decir es que el uso de vistas TAMBIEN
hace que la aplicación sea más optimizable. Para ello lo que puedes
hacer es cambiar el código de la definición de las vistas para
aumentar el rendimiento y sin afectar a la aplicación cliente ya
estando en producción, sin tener acceso al código fuente, sin tener
que recompilar la aplicación ni volverla a desplegar.

No entiendo que es lo que no entiendes de esto que es de libro.

Y además las vistas tienen otras ventajas que no tienen los
procedimientos almacenados como por ejemplo que pueden ser
actualizables, que se pueden filtrar y proyectar fácilmente, que
sirven de base para crear nuevas vistas, etc.


Saludos
Alfredo

Estas consultas son tan sencillas que es
evidente que no se pueden optimizar más, y por lo tanto no tiene
sentido perder tiempo para encapsularlas más.

Aunque una consulta como esta:

SELECT <lista de campos>
FROM MiVista
WHERE <la condicion>

Sea muy sencilla. Lo único que estamos consiguiendo con respecto a esta
otra:

SELECT <lista de campos>
FROM ( la definicion enorme de la vista de 72 líneas ) AS MiVista
WHERE <la condicion>

En cuanto a rendimiento, es la reducción del tráfico de red. Porque las dos
consultas tienen el mismo plan de ejecución. Si la consulta es pesada, como
se supone que es, el aumento del rendimiento debido a la reducción del
tráfico de red es inapreciable comparado con la propia ejecución de la
consulta.

O sea, que es totalmente cierto que las vistas por sí mismas no aceleran el
rendimiento.

La primera versión de esa vista tenía un rendimiento aceptable pero no
demasiado bueno y la he optimizado sin tener que tocar para nada las
aplicaciones. En este caso no se usan vistas indizadas.

No lo dudo.

Macho, para eso imagínate que usas MySQL 2.0 y entonces tampoco te
sirve crear un procedimiento almacenado por que no se puede crear.

Yo uso SQL Server, no MySQL 2.0. Y SQL Server tiene procedimientos
almacenados que me reportan beneficios usar.

Si usas SQL Server estandar y necesitas utilizar vistas indizadas de
forma intensiva, entonces te tienes que pasar a la versión empresarial
o a Oracle y pasar de la chapuza del NOEXPAND. Así que este ejemplo
tiene muy poco valor igual que los demás.

No todo el mundo tiene dinero para compar la versión empresarial. Y por muy
chapuza que sea NOEXPAND es la solución para que se usen las vistas
indexadas en las ediciones Express, Standard y Workgroup.

Y yo te estoy intentando transmitir que con vistas se puede hacer lo
mismo de una forma bastante más flexible y facilitandoles el trabajo a
los desarrolladores de aplicaciones cosa que es una de las
responsabilidades de un buen DBA.

Si bien la vistas también sirven para encapsular, y reescribir una vista
puede aumentar el rendimiento, los procedimientos almacenados tienen otras
características que no cubren las vistas. Son cosas diferentes con
funcionalidades diferentes.

Macho, todos estos ejemplos son muy chorras. Yo presupongo que trabajo
con programadores que no son simios y que no intentan bajar el
rendimiento a propósito.

Lamento mucho que tengas tan mala opinión de los desarrolladores de
aplicaciones. Aunque chorras, esos son ejemplos de la vida real que hacen
ineficientes las aplicaciones. Todos hemos sido novatos alguna vez y no
todos los desarrolladores escriben siempre código SQL bueno.

Nadie está libre de cometer algún error que haga ineficiente el código.
Usando procedimientos almacenados eso tiene fácil solución.

Otro ejemplo extraño que intenta explotar un defecto de diseño de SQL
Server. Esa consulta debería de devolver un error.

Es un ejemplo de la vida real. Nada es perfecto en esta vida y por supuesto
SQL Server tampoco. Aceptemos las cosas tal y como son.

Lo acabo de probar ahora mismo y el plan dice que si que usa el índice
cluster y que hace 'seek' en lugar de 'scan', y me salen exactamente
los mismos costes estimados.

¿Lo has probado también en SQL Server 2000? Porque ese problema se da en SQL
Server 2000 y en SQL Server 2005 no.

No es una exageración es la eterna discusión de alto nivel contra bajo
nivel que se repite una y otra vez a lo largo de las décadas. Tiene
bastante poco suspense quien va a ganar al final.

Los procedimientos almacenados no cambian el nivel, al fin y al cabo sólo
tienen código T-SQL, el mismo código T-SQL que enviaría la aplicación
cliente.

Por otra parte, me trae sin cuidado quien vaya a ganar o perder esta
discusión. Lo importante es que se vean las opiniones y las razones que
tiene cada uno para defender su postura.

El problema es que estás creando una fachada de bajo nivel y muy
rígida por encima de una fachada mucho más flexible y de mucho más
alto nivel, y aun encima estás trabajando bastante para empeorar las
cosas.

No estoy creando nada de bajo nivel, estoy utilizando código T-SQL que
encapsulo en procedimientos almacenados que proporcionan el interfaz de
acceso a la base de datos. Y las cosas mejoran bastante.

No estamos hablando de las aplicaciones estamos hablando de la base de
datos y las vistas son una parte fundamental para la creación del
nivel externo de una base de datos como puedes ver en los primeros
capítulos de cualquier libro de introducción a la materia.

No discuto que las vistas sean una parte fundamental ni estoy en contra de
su uso. Yo no he dicho en ningún momento que no deberían usarse la vistas.
De hecho, en nuestro SolidRAD es una parte fundamental.

Ahí es a donde quería yo llegar. Cuando algo como LINQ funcione bien
no tendrá sentido seguir utilizando "frameworks" primitivos entre
otras cosas por que saldría carísimo y se tardaría muchísimo y quien
te iba a asegurar que fuese más eficiente que LINQ 2034 :-)

Cuando llege LINQ 2034 nos replantearemos nuestra estrategia de acceso a
datos. Mientras tanto esto es lo hay.

Por cierto, no sé a qué frameworks primitivos te refieres, ya que no lo
mencionas, ni tampoco por qué saldrá tan caro, ni por qué se tardaría tanto.

Hombre, en lo que si que estoy completamente de acuerdo es en que es
mucho mejor un procedimiento almacenado que un procedimiento que
calcule datos en las aplicaciones.

Yo estaba hablando de eso. Sino de la optimización de un procedimiento
almacenado. Por otra parte no siempre T-SQL es lo más eficiente, a veces
resulta más eficiente hacer ciertos cálculos en otra capa.

Saludos:

Jesús López
www.solidq.com

On Tue, 15 Apr 2008 18:29:41 +0200, "Jesús López"
wrote:

Aunque una consulta como esta:

SELECT <lista de campos>
FROM MiVista
WHERE <la condicion>

Sea muy sencilla. Lo único que estamos consiguiendo con respecto a esta
otra:

SELECT <lista de campos>
FROM ( la definicion enorme de la vista de 72 líneas ) AS MiVista
WHERE <la condicion>

En cuanto a rendimiento, es la reducción del tráfico de red. Porque las dos
consultas tienen el mismo plan de ejecución. Si la consulta es pesada, como
se supone que es, el aumento del rendimiento debido a la reducción del
tráfico de red es inapreciable comparado con la propia ejecución de la
consulta.

Lo que estamos consiguiendo es que si viene un DBA más listo y
consigue reescribir la vista de forma que sea mucho más rápida,
entonces podremos mejorar el rendimiento sin tocar las aplicaciones,
que es justo de lo que estamos hablando.

Si la consulta de las 72 líneas está incrustada en la aplicación
obviamente no podremos hacer esto.

O sea, que es totalmente cierto que las vistas por sí mismas no aceleran el
rendimiento.

Pero esto no lo había afirmado nadie, igual que los procedimientos
almacenados tampoco aceleran por si mismos el rendimiento.

La primera versión de esa vista tenía un rendimiento aceptable pero no
demasiado bueno y la he optimizado sin tener que tocar para nada las
aplicaciones. En este caso no se usan vistas indizadas.

No lo dudo.

Pues entonces está claro que se pueden conseguir las mismas
oportunidades de optimización sin afectar a las aplicaciones con
vistas que con procedimientos almacenados :-)

Macho, para eso imagínate que usas MySQL 2.0 y entonces tampoco te
sirve crear un procedimiento almacenado por que no se puede crear.

Yo uso SQL Server, no MySQL 2.0. Y SQL Server tiene procedimientos
almacenados que me reportan beneficios usar.

Y yo uso SQL Server empresarial y tiene una implementación de las
vistas indizadas que me reporta beneficios sin la ñapa del NOEXPAND
:-)

Y sino, también está Oracle.

Si usas SQL Server estandar y necesitas utilizar vistas indizadas de
forma intensiva, entonces te tienes que pasar a la versión empresarial
o a Oracle y pasar de la chapuza del NOEXPAND. Así que este ejemplo
tiene muy poco valor igual que los demás.

No todo el mundo tiene dinero para compar la versión empresarial. Y por muy
chapuza que sea NOEXPAND es la solución para que se usen las vistas
indexadas en las ediciones Express, Standard y Workgroup.

Pues te concedo que en este caso y quizás en algún otro si podemos
usar un procedimiento almacenado en lugar de una vista :-)

Y yo te estoy intentando transmitir que con vistas se puede hacer lo
mismo de una forma bastante más flexible y facilitandoles el trabajo a
los desarrolladores de aplicaciones cosa que es una de las
responsabilidades de un buen DBA.

Si bien la vistas también sirven para encapsular, y reescribir una vista
puede aumentar el rendimiento, los procedimientos almacenados tienen otras
características que no cubren las vistas. Son cosas diferentes con
funcionalidades diferentes.

Pero comparten la funcionalidad de permitir mejorar el rendimiento sin
afectar a las aplicaciones, que es lo que estábamos discutiendo :-)

Y por lo tanto si los desarrolladores prefieren vistas para
desarrollar más rápido no vale poner como excusa que luego no vamos a
poder mejorar el rendimiento sin tocar las aplicaciones en producción
por que es falso.

Lamento mucho que tengas tan mala opinión de los desarrolladores de
aplicaciones.

Solo de los que hacen cosas como esas.

Aunque chorras, esos son ejemplos de la vida real que hacen
ineficientes las aplicaciones.

Para eso están las revisiones de código, y los jefes de proyecto y los
analistas senior.

Todos hemos sido novatos alguna vez y no
todos los desarrolladores escriben siempre código SQL bueno.

Si les das vistas con todo ya masticado es muy difícil que lo hagan
mal sin ser a propósito :-)

Nadie está libre de cometer algún error que haga ineficiente el código.
Usando procedimientos almacenados eso tiene fácil solución.

Con procedimientos almacenados tampoco estás a salvo de un programador
incompetente, por que te puede poner las llamadas dentro de un bucle o
cualquier otra barbaridad.

Por ejemplo si tienes un procedimiento almacenado para actualizar un
registro y no les das acceso a las tablas, entonces podrían intentar
actualizar un millón de registros haciendo un millón de llamadas al
procedimiento almacenado. Y cosas como estas son mucho más frecuentes
que las de tus ejemplos.

¿Lo has probado también en SQL Server 2000? Porque ese problema se da en SQL
Server 2000 y en SQL Server 2005 no.

Eso se avisa, yo nunca he usado SQL Server 2000 por que no era lo
suficientemente bueno para mi :-)

No es una exageración es la eterna discusión de alto nivel contra bajo
nivel que se repite una y otra vez a lo largo de las décadas. Tiene
bastante poco suspense quien va a ganar al final.

Los procedimientos almacenados no cambian el nivel, al fin y al cabo sólo
tienen código T-SQL, el mismo código T-SQL que enviaría la aplicación
cliente.

Aquí no me refiero a los procedimientos almacenados, me refiero a si
usar LINQ o usar los "frameworks" tradicionales como los DataSets

Por otra parte, me trae sin cuidado quien vaya a ganar o perder esta
discusión. Lo importante es que se vean las opiniones y las razones que
tiene cada uno para defender su postura.

No me refería a ganar o perder la discusión, sino a que tipo de
"framework" va a triunfar a la larga.

El problema es que estás creando una fachada de bajo nivel y muy
rígida por encima de una fachada mucho más flexible y de mucho más
alto nivel, y aun encima estás trabajando bastante para empeorar las
cosas.

No estoy creando nada de bajo nivel, estoy utilizando código T-SQL que
encapsulo en procedimientos almacenados que proporcionan el interfaz de
acceso a la base de datos. Y las cosas mejoran bastante.

No me has entendido. Una "fachada" de procedimientos es una interfaz
de mucho más bajo nivel que poder usar SQL en toda su potencia.

Por cierto, no sé a qué frameworks primitivos te refieres, ya que no lo
mencionas, ni tampoco por qué saldrá tan caro, ni por qué se tardaría tanto.

A todos los que no permiten consultas integradas en el código de las
aplicaciones con comprobación de sintaxis, tipos e intellisense.

Hombre, en lo que si que estoy completamente de acuerdo es en que es
mucho mejor un procedimiento almacenado que un procedimiento que
calcule datos en las aplicaciones.

Yo estaba hablando de eso. Sino de la optimización de un procedimiento
almacenado. Por otra parte no siempre T-SQL es lo más eficiente, a veces
resulta más eficiente hacer ciertos cálculos en otra capa.

En un procedimiento almacenado CLR.

Pero hay que tener mucho cuidado con esto por que muchísimas veces hay
programadores que quieren llevarse código a las aplicaciones no por
que sea mejor sino por que no dominan T-SQL.



Saludos

hola jesus, ps mira estoy empezando hacer mis practicar profesionales en una
empresa y lo que me designaron hacer es optimizar consultas sql, es la
primera vez que hago esto y no tengo mucho conocimiento en las formas y
procesos para optimizar una consulta, lo he intentado hacer con lo poco que
se con metodos y formas que conosco pero no veo mucho cambio mas bien no hay
cambios en el rendimiento de la consulta, y esto si me preocupa por que no
encuentro la manera adecuada de llevar esto, y me gustaria que me ayudaras
por favor... mandandome ejemplos de consultas optimizadas el antes y el
despues, procesos o metodos que debo utilizar, incluso reglas que debo
seguir, te lo agradeceria mucho



espero contar con tu ayuda.



saludos