Stored Procedures are bad?

muy bien, para estas pocas 'excepciones', vale la pena 'desnormalizar'


saludos,


Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com


"Miguel Egea" escribió en el mensaje
news:

Hola Antonio, lo cierto es que el tema de la velocidad y los sp's siempre
fué discutible, ni siquiera que esté cacheado en el servidor es garantía
de que se ejecute más rápido, por ejemplo yo me encontré un sp, que se
ejecutaba unas 30.000 veces por minuto y que hacía más de 40000 lecturas
lógicas, simplemente hacia una comparación del tipo
Campoclave= isnull(@parametro,0) y otro montón de ands, esa misma consulta
parametrizada habría hecho 3 lecturas lógicas (mira el orden de magnitud
que se ganaba). Sin embargo lo que a mi me gusta de los sp's es que una
vez que determiné que ese era el problema ( y me costó menos de 1 hora
averiguarlo) solucionarlo fué tan sencillo como añadir un if, no digo que
el optimizador de consultas no pudiese haber hecho un mejor trabajo,
seguro que sí, sin embargo ese cambio, en código generado en la aplicación
en una aplicación desplegada en más de 1000 puestos de usuario, habría
sido una semana de trabajo y con sp's, lo solucionamos en 1,5 horas. Es
cierto que en tiempo de desarrollo a los desarrolladores igual le cuesta
menos pensar en SQL "al vuelo", pero ejemplos como este y experiencias
como estas son lo que me hacen ser defensor a ultranza de procemdimientos
almacenados para todo. (Y no pretendo crear polémica, sé que otros son
partidarios de solo en partes, y otros de ninguno, y si funciona, pues
amén, nada que objetar).

Sobre las relaciones 1:1, yo si me he encontrado, sobre todo en cosas como
datos fiscales obligatorios del cliente y otros datos no obligatorios, en
los que la parte derecha es opcional, En un desarrollo me encontré una
tabla de 15 millones de clientes de los cuales menos del 1% tenían datos
adicionales, simplemente separar eso en dos tablas mejoró más de un 10% el
rendimiento global del sistema, aunque lo cierto es que si son raras las
ocaciones en que son necesarias.

Saludos
Miguel Egea

"Antonio Ortiz" wrote in message
news:ON%

Un saludo Miguel:

Gracias por aportar a este tema. Lo unico que debati al instructor fue su
afirmacion que las sentencias Transact dentro de los SP's ejecutan 40%
mas rapido que SQL Dinamico (no se de donde saco dicho porcentaje). Debo
mencionar que mis respetos al tipo, denotaba conocimientos profundos de
infraestructura y practica en desarrollo, sin embargo nos trato a todos
como novatos y nunca se espero que alguien le debatiera algo y su unico
argumento como respuesta fue: 'en esto yo soy experto'.

Por cierto, el debate sobre las relaciones 1 a 1, la misma documentacion
de Access dice:
"Este tipo de relación no es normal, porque la mayoría de la información
que se relaciona de esta forma estaría en una tabla. Puede utilizar la
relación uno a uno para dividir una tabla con muchos campos, para aislar
parte de una tabla por razones de seguridad o para almacenar información
que sólo se aplica a un subconjunto de la tabla principal. "

. Y he de mencionar que en mis 15 años desarrollando software jamas me
encontre una situacion donde debiera utilizar relaciones 1 a 1.


saludos,


Antonio Ortiz
asesor en sistemas
ant(a)aortiz.net
www.aortiz.net
www.progvisual.com





"Miguel Egea" escribió en el mensaje
news:

Yo creo que hay razones sobradas para usar sp's, se han dicho en este
grupo hasta la saciedad, sin embargo la más importante para mí es la
analogía con el desarrollo de aplicaciones. Cuando creas un objeto
accedes a través de métodos y propiedades, por que eso te permite
cambiar el comportamiento sin cambiar la interfaz y que todo siga
funcionando ¿porque eso no habría de aplicar en la base de datos? Si el
sistema es de misión critica hay mil y una cosas que un buen dba puede
hacer si el acceso es a través de sp's y sin embargo tiene las manos
mucho más atadas si no lo es.

Esa es mi opinión.

Saludos
Miguel Egea
(muchas gracias Antonio, hacía siglos que no leía tu nombre y me ha
encantao volver a leerlo :))

"Antonio Ortiz" wrote in message
news:%23N%

Un interesante articulo, lo expongo para enriquecer el tema sin afan de
defender tal o cual posicion. Lo ironico es que el autor del articulo
es el mismo que creo la herramienta LLBLGen, que permite generar codigo
para SP y clases .Net para la capa de datos.

Su articulo 'Stored Procedures are bad'
http://weblogs.asp.net/fbouma/archi...38178.aspx

Descarga de LLBLGen
http://www.microsoft.com/downloads/...x?FamilyID›F77697-10B0-42CA-AFE9-B76044B3D2AF&displaylang=en


Investigue un poco el tema a raiz de que un instructor se ofendio
cuando le dije que no estaba de acuedo en la afirmacion 'Los Stored
Procedures ejecutan mas rapido que las consultas dinamicas'. En mi
opinion el unico argumento sostenible para utilizar SP es 'buenas
practicas'.


saludos,

Antonio Ortiz
asesor en sistemas
www.aortiz.net
www.progvisual.com

El Sun, 25 May 2008 18:08:07 +0200, Miguel Egea escribió:

de consultas no pudiese haber hecho un mejor trabajo, seguro que sí, sin
embargo ese cambio, en código generado en la aplicación en una aplicación
desplegada en más de 1000 puestos de usuario, habría sido una semana de
trabajo y con sp's, lo solucionamos en 1,5 horas.

Si el cambio hubiese estado en una vista habría sido el mismo trabajo que
con el SP.

Cuando tienes una aplicación en más de 1000 puestos es bastante conveniente
tener un sistema automático de actualizaciones por razones obvias. O
también puedes usar una aplicación Web o RIA.

Sobre las relaciones 1:1, yo si me he encontrado, sobre todo en cosas como
datos fiscales obligatorios del cliente y otros datos no obligatorios, en
los que la parte derecha es opcional, En un desarrollo me encontré una tabla
de 15 millones de clientes de los cuales menos del 1% tenían datos
adicionales, simplemente separar eso en dos tablas mejoró más de un 10% el
rendimiento global del sistema, aunque lo cierto es que si son raras las
ocaciones en que son necesarias.

Pues si incluyo las relaciones 1:1 o 0 entonces para mi son lo más normal
del mundo.


Saludos
Alfredo

Hola Antonio,

El Sun, 25 May 2008 10:38:13 -0600, Antonio Ortiz escribió:

muy bien, para estas pocas 'excepciones', vale la pena 'desnormalizar'

Me he perdido. ¿Que tiene que ver "desnormalizar" con lo que ha dicho
Miguel?


Saludos
Alfredo

El Sun, 25 May 2008 11:56:10 -0300, Maxi Accotto escribió:

Pues este argumento ha sido rebatido en este grupo hasta la saciedad. Se
ve
que llevas tiempo sin pasarte por aquí :-)

Si, solo por ti, y quien sos vos? ya te han demostrado que muchos gurues y
con argumentos de la realidad (no solo libros y teoria como la tuya) los
hacen a un buen diseño y luego mantenimiento de todo el sistema, o sea: que
tu lo hayas reflutado no quiere decir que sea la verdad y que los
profesionales piensen como vos, y hagan las cosas como vos.

La verdad que leerte da risa, es como que haces copy paste de internet y
solo tenes teoria, hasta me da la impresion que nunca has hecho un sistema
pero bueno..

Maxi, por favor, deja de comportarte como un idiota.

"Antonio Ortiz" escribió en el mensaje
news:%23N%

Un interesante articulo, lo expongo para enriquecer el tema sin afan de
defender tal o cual posicion. Lo ironico es que el autor del articulo es
el mismo que creo la herramienta LLBLGen, que permite generar codigo para
SP y clases .Net para la capa de datos.

Hola,

Frans omite un argumento que habría que tomar en cuenta, y que es MUY
importante desde el punto de vista del desarrollador de aplicaciones.

Los SP te permiten tener (parte de) la lógica de tu aplicación fuera del
programa compilado. Si tienes un procedimiento que produce determinados
efectos, y en un momento dado a un cliente se le mete en la cabeza que no
quiere que tal efecto se produzca, o se produzca de otra manera, o que se
produzca un efecto adicional, te bastará con modificar el SP en la BD del
cliente, sin tocar tu código fuente, y sin cambiarle nada a nadie más.

Pero de ahí a la opinión casi religiosa de que hay que escribir un SP hasta
para la consulta más trivial, hay una gran diferencia.

Salud!