LINQ ?

hola jesus lopez, 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.

mi correo es

saludos

Hola Jesús,

On 15 apr, 13:18, "Jesús López"
wrote:

Creo que no me has entendido, o no me he explicado bien.

Creeme. Te he entendido muy 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.

Son conceptos totalmenten distintos. Una vista no es para reducir el
tráfico, de la misma forma que una tabla tampoco es para eso. Una
vista accesible desde fuera es parte del diseño lógico (de la
estructura) de una base de datos, independiente de las aplicaciones.
Un procedimiennto almacenado es parte de 'una' aplicación o grupo de
aplicaciones, llevada a la base de datos.

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

Pues a mi me pareció que eras tu el que los estaba comparando. Y
puestos a eso no me pongas un ejemplo de vistas mal estructuradas
para argumentar que es mejor hacerlo en un procedimiento.

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.

Ya se te ha explicado que lo mismo se puede decir de las vistas.

Pero quiero añadir que con lo que estás diciendo sobre sp's, estás
hablando de código de la aplicación, 'una' aplicación. Por mucho
que lo pongas físicamente en la bbdd no es a nivel lógico el
lugar que le corresponde ni un argumento para deshacerse de
las vistas.

El hecho es que estoy continuamente viendo como una bbdd se suele
ver como una biblioteca de procedimientos que le convienen a una
u otra aplicación. Esta discusión es otro ejemplo de ello.
Pero una bbdd no es eso. Es una estructura lógica, con mecanismos
para garantizar la integridad y para consultar (y actualizar), y
derivar datos. Eso se consigue con tablas (vistas son tablas),
reglas de integridad y con un lenguaje relacional. En este cuadro
los sp's no aparecen por ningun lado.

A veces me da la impresión de que muchos lo que quieren es
no dar acceso a las tablas (lease también vistas) y montar
solo una biblioteca de SP's. Un nivel mucho más bajo.

Saludos,
Carlos

On 15 apr, 14:07, "Jesús López"
wrote:

Seguro que en el foro de SQL Server habrá mucha más gente partidaria de los
procedimientos almacenados.

Claro que hay!! :) Hay modas con un nivel de acceptación enorme
el mundo de la informática

Saludos,
Carlos

Yo no estoy ni he estado nunca en contra de las vistas. Ni he dicho que las
vistas estén para reducir el tráfico de red. He dicho que las vistas
contribuyen a reducir el tráfico de red que es algo bastante diferente.

Mi argumento a favor de los procedimientos almacenados es el siguiente:

En cuanto al rendimiento, si el código SQL que envían las aplicaciones al
servidor de base de datos están en procedimientos almacenados entonces la
aplicación es más optimizable. porque puede cambiarse dicho código sin tener
acceso al código fuente y sin tener que recompilar la aplicación y sin
necesidad de volver a desplegarla. Lo que hace el trabajo de los DBA's y de
las personas contratadas para optimizar la aplicación más fácil.

En cuanto a seguridad, permiten una mayor granularidad en la autorización.

En cuanto diseño permiten una encapsulación y abstración.

Es cierto que puedes modificar la definición de una vista y aumentar el
rendimiento, al igual que con un procedimiento almacenado. Pero ¿qué ocurre
con las consultas que se hacen sobre las vistas? ¿con sus cláusulas where?
¿Con consultas que que acceden varias tablas y vistas al mismo tiempo?. No
puedes reescribir la cláusula where porque no está en la vista, la envía la
aplicación y está en la consulta que accede a la vista. No puedes reescibir
las consultas que acceden a varias vistas, etc, etc. Es decir, si yo tengo
todo el código SQL que envía la aplicación en procedimientos almacenados,
puedo reescribirlo todo para optimizarlo, sin embargo si sólo uso vistas no
puedo optimizarlo todo.

Además el código SQL que envía una aplicación no se trata exclusivamente de
simples accesos a tablas y vistas, sino que hay procesos más complejos que
conviene encapsular en procedimientos almacenados.


Hablo de aplicaciones y procedimientos almacenados, en vez de bases de datos
tablas y vistas como conceptos lógicos, porque al fin y al cabo son las
aplicaciones las que explotan la base de datos. Y en definitiva, al final lo
que hacen las aplicaciones es enviar código SQL al servidor de base de
datos. ¿Es que se va a reducir alguna funcionalidad de las aplicaciones
porque almacenemos ese código SQL en procedimientos almacenados? Pues no.

Después de ya muchos mensajes en este hilo, la verdad es que no he oído
ninguna razón realmente práctica por la que no se debería encapsular el
código SQL en procedimientos almacenados.


Y ya por último prometo no seguir con el tema, porque ya creo que le hemos
dado muchas vueltas y empiezo a sentirme un poco cansado.

Saludos:

Jesús López
www.solidq.com

José,

Empieza por buscar y leer artículos en Internet acerca de la optimización de
consultas, planes de ejecución, índices, etc. Luego selecciona las consultas
a optimizar. Generalmente no es necesario optimizarlas todas al máximo,
porque en las aplicaciones suele ocurrir que el hay un 10-5% de las
consultas que se llevan el 80-90% del procesamiento del servidor. Es en
esas consultas en las que deberías concentrar tus esfuerzos. Si no sabes qué
hacer para optimizar una consulta en concreto, pregunta en el grupo de SQL
Server, allí estaremos para ayudarte. Te podemos ayudar a optimizar las
consultas una por una, o resolver una duda en concreto del proceso de
optimización o ayudarte a entender por qué es más eficiente una consulta en
concreto que otra, pero por favor no nos pidas que te enseñemos a optimizar
consultas así de forma genérica, porque eso es algo que requiere bastante
tiempo y dedicación.

Saludos:

Jesús López
www.solidq.com



"jose" escribió en el mensaje
news:

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