LINQ ?

On Wed, 16 Apr 2008 00:38:12 +0200, "Jesús López"
wrote:

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

Las vistas también permiten una gran granularidad en la autorización.

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

Las vistas también permiten encapsulación y abstracció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?

Pues que te dan una versatilidad y flexibilidad que no tienes con los
SP.

¿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.

Es que tampoco hace falta poder optimizarlo todo. Hay que llegar a un
equilibrio entre rendimiento y flexibilidad.

Además un select lista_campos from vista where condición no es que se
pueda optimizar mucho si los programadores tienen dos dedos de frente.

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.

Pues claro, los procedimientos almacenados también tienen sus usos. A
lo que yo me opongo es a ocultar sistemáticamente (descerebradamente)
tablas y vistas usando procedimientos almacenados, que es algo
desgraciadamente bastante común.

Yo por ejemplo uso bastante los procedimientos almacenados para crear
registros automáticamente, aunque por supuesto intento que los
procedimientos por dentro sean lo más declarativos que sea posible.

Y también uso funciones definidas por el usuario, que también son
procedimientos almacenados que devuelven valores escalares.

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.

Pues creo que ya se ha dicho bastantes veces, por que usar consultas
SQL sobre un juego de tablas te puede ahorrar la escritura de montones
y montones de procedimientos almacenados que no añaden valor. Si solo
expones una bibiloteca de procedimientos almacenados, cada vez que las
aplicaciones tengan que implementar una nueva funcionalidad los
desarrolladores se tienen que poner en contacto con el DBA para que
les cree un montón de procedimientos almacenados nuevos. Y con las
modificaciones todavía es peor. De esta forma estás desperdiciando
buena parte del ahorro de trabajo que puede proporcionar un SGBD.

Trabajar con procedimientos almacenados desde las aplicaciones es
mucho más engorroso que trabajar con tablas y vistas. Con una buena
herramienta RAD se pueden hacer un montón de cosas sin escribir una
sola linea de código. Con procedimientos almacenados al parecer solo
existe vuestra herramienta que aun esta por ver si puede alcanzar el
nivel de productividad del que disfrutamos desde hace muchos años con
heramientas como VFP, Power Builder, Delphi, Oracle Forms, etc.


Saludos

La cosa es que reescibiendo y optimizando las vistas no puedes corregir el
código SQL ineficiente que puede encontrase por ejemplo en la cláusula where
de una consulta como esta:

SELECT <lista de campos>
FROM MiVista
WHERE <Una condición>

Suponte que el problema de rendimiento de esta consulta está precisamente
en que la cláusula where es digamos defectuosa.

Si embargo, si lo tienes en un procedimiento almacenado sí que lo puedes
hacer.

Por otra parte, seguramente habrá en la aplicación consultas que accedan a
varias vistas como esta:

SELECT <Lista de campos y además agregados y además llamadas a funciones
escalares>
FROM Vista1 JOIN Vista2 JOIN Vista3
ON <las condiciiones de los join>
WHERE <la condición del filtro>
GROUP BY <campos del group by>

Resulta que tampoco podemos optimizar esta consulta si el problema de
rendimiento no radica en la definicion de las vistas sino en como está
escrita la consulta. Y también es posible que la consulta pudiera escribirse
de otra manera sin acceder varias veces a la misma tabla, porque resulta que
cierta tabla aparece tanto en la Vista1 como en la Vista2.

En definitiva, aunque reescribiendo y optimizando las vistas puedes mejorar
el rendimiento de ciertas consultas, no las puedes optimizar todas, mientras
que con los procedimientos almacenados sí.


Por útlimo, hay maneras de conseguir que el uso de procedimientos
almacenados no suponga ni un coste ni un tiempo excesivo de desarrollo. Para
ello existen herramientas como por ejemplo el "Generador de clases para
procedimientos almacenados":

http://blogs.solidq.com/ES/CuevaNet...st.aspx?ID


También puedes encontrar por ahí muchas generadores de procedimientos
almacenados. Y por supuesto nuestra herramienta SoldRAD.


Saludos:

Jesús López
www.soldiq.com

Pues creo que ya se ha dicho bastantes veces, por que usar consultas
SQL sobre un juego de tablas te puede ahorrar la escritura de montones
y montones de procedimientos almacenados que no añaden valor. Si solo
expones una bibiloteca de procedimientos almacenados, cada vez que las
aplicaciones tengan que implementar una nueva funcionalidad los
desarrolladores se tienen que poner en contacto con el DBA para que
les cree un montón de procedimientos almacenados nuevos. Y con las
modificaciones todavía es peor. De esta forma estás desperdiciando
buena parte del ahorro de trabajo que puede proporcionar un SGBD.

Pero el código SQL hay que escribirlo de todas formas. Mucho mejor si está
metido en procedimientos almacenados que incrustado en la aplicación
cliente. Al DBA sólo hay que pasarle un script y estará encantado al ver que
son procedimientos almacenados.

La versatilidad y la flexibilidad es la misma, porque al fin y al cabo el
código SQL es el mismo.

Las vistas no proporcionan tanta granularidad en la autorización como los
procedimientos almacenados.

Por supuesto que no va a hacer falta optimizarlo todo, pero deberíamos tener
la posibilidad de optimizarlo todo. ¡Qué casualidad que aquello que no puede
optimizarse es lo que más nos está degradando el rendimiento!


"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 16 Apr 2008 00:38:12 +0200, "Jesús López"
wrote:

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

Las vistas también permiten una gran granularidad en la autorización.

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

Las vistas también permiten encapsulación y abstracció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?

Pues que te dan una versatilidad y flexibilidad que no tienes con los
SP.

¿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.

Es que tampoco hace falta poder optimizarlo todo. Hay que llegar a un
equilibrio entre rendimiento y flexibilidad.

Además un select lista_campos from vista where condición no es que se
pueda optimizar mucho si los programadores tienen dos dedos de frente.

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.

Pues claro, los procedimientos almacenados también tienen sus usos. A
lo que yo me opongo es a ocultar sistemáticamente (descerebradamente)
tablas y vistas usando procedimientos almacenados, que es algo
desgraciadamente bastante común.

Yo por ejemplo uso bastante los procedimientos almacenados para crear
registros automáticamente, aunque por supuesto intento que los
procedimientos por dentro sean lo más declarativos que sea posible.

Y también uso funciones definidas por el usuario, que también son
procedimientos almacenados que devuelven valores escalares.

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.

Pues creo que ya se ha dicho bastantes veces, por que usar consultas
SQL sobre un juego de tablas te puede ahorrar la escritura de montones
y montones de procedimientos almacenados que no añaden valor. Si solo
expones una bibiloteca de procedimientos almacenados, cada vez que las
aplicaciones tengan que implementar una nueva funcionalidad los
desarrolladores se tienen que poner en contacto con el DBA para que
les cree un montón de procedimientos almacenados nuevos. Y con las
modificaciones todavía es peor. De esta forma estás desperdiciando
buena parte del ahorro de trabajo que puede proporcionar un SGBD.

Trabajar con procedimientos almacenados desde las aplicaciones es
mucho más engorroso que trabajar con tablas y vistas. Con una buena
herramienta RAD se pueden hacer un montón de cosas sin escribir una
sola linea de código. Con procedimientos almacenados al parecer solo
existe vuestra herramienta que aun esta por ver si puede alcanzar el
nivel de productividad del que disfrutamos desde hace muchos años con
heramientas como VFP, Power Builder, Delphi, Oracle Forms, etc.


Saludos

ok muchas gracias, me podrias decir en ke parte esta este grupo, sql server,
para poder acceder.

mira aki dejo una ejemplo de una consulta para ver cual seria la mejor forma
de optimizarla o bien si esta bien asi como esta, a ver si me puedes ayudar.

SELECT eqp_cve_equipo, eqp_rpe_coordinador, emp_nombre,
emp_apellido_paterno, emp_apellido_materno, eqp_cve_area,
aar_descripcion
FROM equipos_procesos, empleados, areas_agencias
WHERE eqp_cve_area IN (SELECT aar_cve_area
FROM areas_agencias
WHERE aar_equivalencia LIKE
cve_divzona)
AND eqp_cve_proceso LIKE procesocve_tot
AND emp_rpe = eqp_rpe_coordinador
AND eqp_cve_area = aar_cve_area
ORDER BY eqp_cve_equipo;

NOTA: las variables de cve_divzona y procesocve_tot tienen valores aleatorios