Stored Procedures are bad?

Pues hasta ahora yo he creado y mantenido aplicaciones con bases de datos
pequeñas (hasta 1 gb) muy eficientemente con MSDE 1.0, MSDE 2000 & SQL
Server 2005 Express, donde todas mis consultas son codigo dinamico, y con un
resultado muy optimo en rendimiento he de decir. En ocasiones cerca de 2
decenas de usuarios se han conectado a un 'servidor' Clone AMD XP 2400 que
incluso hace de servidor de camaras, grabando lo de 4 camaras en otro disco
duro. Y uno o dos usuarios via internet (no web). Y debo decir que de estas
aplicaciones he distribuido y se encuentran trabajando mas de 1 millar sin
problemas.

Sin embargo esto fue asi debido a mi poco dominio de SPs, ahora estoy
encaminado a utilizar mas SP's. Sin debatir argumentos a favor o en contra,
mi percepcion es que es una buena practica usar SP's, punto. Aunque eso no
me impide analizar otras opiniones. 'Lo de cesar a cesar...'.


:D

saludos,


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




"Carlos M. Calvelo" escribió en el mensaje
news:
Hola Alfredo,

On 25 mei, 00:25, Alfredo Novoa wrote:
Mostrar la cita

El Sat, 24 May 2008 16:02:18 -0600, Antonio Ortiz escribió:

> En fin, que si escriben SP's ahi tienen una buena herramienta que les
> ayudara :D

> 'LLBLGen'

A lo mejor Carlos nos podría contar un par de cosas sobre LLBLGen o como
se
llame :-)

No voy a comentar porque me he negado a trabajar con LLBLGen Pro,
me he salido con la mía :-), y no lo conozco a fondo. No por ser
LLBLGen Pro en particular; me hubiera negado a trabajar con
cualquier OR-mapper.

He visto lo suficiente para que se confirmaran mis sospechas.
Aún lo tengo instalado en mi laptop :)
Generar una burrada de clases.. etc, etc, con metadatos de
la base de datos, bueno .. ya sabes.

El artículo al que se refiere Antonio Ortiz me ha sorprendido
positivamente. No es lo que hubiera esperado yo de Frans Bouma.

Saludos,
Carlos

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:
Mostrar la cita

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%
Mostrar la cita

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

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%
Mostrar la cita

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:
Mostrar la cita

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%
Mostrar la cita

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

Hola Antonio:

"Antonio Ortiz" escribió en el mensaje de
noticias:ON#

Mostrar la cita

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.

Dentro de mis conocimientos justitos del tema, cuando empecé a estudiarlo,
también me parecía absurdo este tipo de relación, hasta que vi las
relaciones además podían ser de Obligatoria-Opcional y Opcional-Opcional.
Ahí si tienen sentido de alguna forma las relaciones 1 a 1 (salvo que se
esté suponiendo 1:1 como (1,1):(1,1)).

Supongo que a este caso es a lo que se refieren con "almacenar información
que sólo se aplica a un subconjunto de la tabla principal" o eso me parece
entender.

Un saludo

Hola Antonio,

El Sun, 25 May 2008 09:47:48 -0600, Antonio Ortiz escribió:

Mostrar la cita

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

Encontrar información incorrecta en los manuales de los fabricantes de
software es lo más normal del mundo.

Por ejemplo si una tabla almacena información que solo se aplica a un
subconjunto de la tabla principal entonces tenemos una relación 1 a 1 o 0.

Mostrar la cita

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

Pues tampoco son muy raras. Imagínate que tienes una entidad llamada
Departamentos, otra llamada Directores y otra llamada Trabajadores y una
regla que dice que cada departamento tiene un director y N trabajadores.


Saludos
Alfredo