LINQ ?

Alfredo,

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?. Es cierto que una vista indexada puede
acelerar mucho el rendimiento de ciertas consultas. Pero SQL Server va a
utilizar la vista indexada si le conviene incluso sin que se referencie
directamente en la consulta, al menos esto ocurre en la edición empresarial.
Y en las otras ediciones hay que referenciar directamente la vista y además
poner la opcion WITH (NOEXPAND) para que se use el índice de la vista.

Pongamos un ejemplo. Supongamos que tenemos la vista Vista1 que tiene una
par de joins y varios agregados. Vemos que una consulta como esta:

SELECT lista de campos FROM Vista1 WHERE UnaCondicion

Es pesada porque la tablas base son grandes, hay varios joins y además
agregados. Entonces decidimos crear un índice sobre la vista. Si estamos en
la edición empresarial, la consulta utilizará el índice directamente, pero
si estamos en la edición Express, Standard o Workgroup, SQL Server no
utilizará el índice de la vista y tendrá por tanto el mismo rendimiento que
antes. 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, 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

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.

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'

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. Este tipo de cosas las he visto
varias veces cuando he ido a optimizar sistemas en SQL Server, o sea, que no
es nada raro.

Si se estuviera usando un procedimietno almacenado, incluso aunque sus
parametros estuvieran mal declarados. Es decir, algo así:

CREATE PROCEDURE Obtener_Registro_Por_El_ID
@ID varchar(50)
AS

SELECT lista de campos FROM Tabla1 WHERE ID = @ID

Que por cierto, funcionaría igual de mal que la consulta anterior. Pero
podemos moficarlo para que sea eficiente y use el indice:

ALTER PROCEDURE Obtener_Registro_Por_El_ID
@ID varchar(50)
AS

SELECT lista de campos FROM Tabla1 WHERE ID = CONVERT(int, @ID)

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'

Por mucho que queramos crear un índice sobre el campo fecha, SQL Server no
lo va a utilizar al estar encerrado el campo Fecha dentro de una expresión.
Supongamos otra vez que estamos en producción y que la aplicación cliente
envía esta consulta. No podemos hacer nada sin modificar el código de la
aplicación cliente. Sin embargo, si este código estuviera en un
procedimiento almacenado como este:

CREATE PROCEDURE ObtenerTabla1PorFecha
@Fecha datetime
AS
SELECT * FROM Tabla1 WHERE CONVERT(datetime, FLOOR(CONVERT( float,
Fecha))) = @Fecha

Yo lo podría cambiar por este otro:

CREATE PROCEDURE ObtenerTabla1PorFecha
@Fecha datetime
AS
SELECT * FROM Tabla1 WHERE Fecha >= CONVERT(datetime, FLOOR(CONVERT(
float, @Fecha))) AND Fecha < CONVERT(datetime, FLOOR(CONVERT( float,
@Fecha) + 1))


Donde el campo Fecha no está encerrado dentro de una expresión, sino que es
el parámtero el que está en una expresión. Ahora creando un índice sobre el
campo Fecha, SQL Server usará el índice y la consulta será posiblemente
cientos de veces más rápida.

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. 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? ¿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? Esto es una práctica que se
repite constantemente.


Sé que a muchos desarrolladores no les gustan los procedimientos
almacenados, quizá porque no les vean muchas ventajas en la fase de
desarrollo, pero se olvidan de las que se tienen en producción. Por eso
nosotros hemos creado una herramienta RAD que basa su acceso a datos en
procedimientos almacenados, para que a los desarrolladores les resulte más
atractivo su uso.

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. 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. No pensemos solo en lo nos conviene
a los desarrolladores y en la fase de desarrollo. La vida de la aplicación
no termina ahí.


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 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?

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.


Saludos:

Jesús López
www.solidq.com





"Alfredo Novoa" escribió en el mensaje
news:

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

Creo que no me has entendido, o no me he explicado bien. El uso de vistas
por sí mismo no acelera el rendimiento, ni el uso de procedimientos
almacenados por sí mismo tampoco si lo comparamos con las consultas
parametrizadas. Los procedimientos almacenados tienen prácticamente el mismo
rendimiento que las consultas parametrizadas equivalentes.

Las vistas y procedimientos contribuyen a reducir el tráfico de red, pero en
la mayoría de los casos el impacto sobre el rendimiento es inapreciable.

De todas maneras no creo que tenga mucho sentido comparar vistas y
procedimientos almacenados, porque son cosas completamente diferentes con
funcionalidades completamente diferentes.

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.

Saludos:


Jesús López
www.solidq.com


"Carlos M. Calvelo" escribió en el mensaje
news:
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

Estoy muy de acuerdo en lo que dices Jesús,

Pero no nos estamos desviando un poco off.-topic. Este hilo en el foro de
SQL Server venia que ni pintado, además de ser muy interesante.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

Hola Pablo,

El caso es que son los desarrolladores los que decidimos si usar
procedimientos almacenados o no, si usar vistas, herramientas RAD, LINQ,
NHibernate, etc, etc.

Si, es posible que me haya desviado un poco, pero quería dar ejemplos
concretos de la vida real de lo que un DBA puede hacer con su magia si le
das la varita (los procedimientos almacenados)

Seguro que en el foro de SQL Server habrá mucha más gente partidaria de los
procedimientos almacenados y entonces la discusión no sería tan interesante
ni sería un reto.

Saludos:

Jesús López
www.solidq.com



"Pablo Roca" escribió en el mensaje
news:

Estoy muy de acuerdo en lo que dices Jesús,

Pero no nos estamos desviando un poco off.-topic. Este hilo en el foro de
SQL Server venia que ni pintado, además de ser muy interesante.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com

y tambien decir que de lo que uno ve en estos foros, sin animos de ser
indulgente, hay pocos como Jesus Lopez, que dominan ambos mundos :
programacion y base de datos. Normalmente los expertos en sql no son muy
diestros en lenguajes de programacion de aplicaciones y viceversa.


"Jesús López" escribió en el
mensaje news:%

Hola Pablo,

El caso es que son los desarrolladores los que decidimos si usar
procedimientos almacenados o no, si usar vistas, herramientas RAD, LINQ,
NHibernate, etc, etc.

Si, es posible que me haya desviado un poco, pero quería dar ejemplos
concretos de la vida real de lo que un DBA puede hacer con su magia si le
das la varita (los procedimientos almacenados)

Seguro que en el foro de SQL Server habrá mucha más gente partidaria de
los procedimientos almacenados y entonces la discusión no sería tan
interesante ni sería un reto.

Saludos:

Jesús López
www.solidq.com



"Pablo Roca" escribió en el mensaje
news:

Estoy muy de acuerdo en lo que dices Jesús,

Pero no nos estamos desviando un poco off.-topic. Este hilo en el foro de
SQL Server venia que ni pintado, además de ser muy interesante.


Saludos,

Pablo Roca
La Coruna - Spain
http://www.portalfox.com