Acceso a Datos (Mejores practicas)

"Jesús López" wrote in message
news:

No estoy de acuerdo Alberto. Los procedimientos almacenados no se han
quedado obsoletos y siguen tendiendo ventajas frente a instrucciones SQL
lanzadas por la aplicación por muy sencillas que sean.

Estoy de acuerdo contigo, los procedimientos siguen siendo útiles. Pero
en todos los casos que has mencionado, se trata de procedimientos
especializados que hacen "algo más" que símplemente reflejar una única
sentencia SQL sencilla. La observación que yo hacía es que si símplemente
vas a hacer un "select * from mitabla", no merece la pena meterlo dentro de
un procedimiento almacenado; para eso, lo ejecutas directamente y ya está.
Concedo que en este caso el tráfico de red es ligeramente mayor, ya que
"select * from mitabla" es algo más largo que "exec miproc", pero la
diferencia es insignificante en comparación con el volúmen de los datos
devueltos, que es el mismo en ambos casos. Desde luego, si el "select" fuera
un gigantesco join de una docena de tablas sí que podría merecer la pena
dejarlo dentro de un procedimiento.

Las ventajas de los procedimientos almacenados siguen vigentes y no han
sido superadas en absoluto. Quien haya dicho lo contrario se equivoca de
plano y nunca ha sido DBA ni nunca ha ido a optimizar una aplicación en
producción.

De acuerdo, pero también hay que balancearlo contra el problema
contrario: el abuso de los procedimientos almacenados. Cuando todo,
absolutamente todo, hasta las sentencias más sencillas, se encapsula dentro
de un procedimiento almacenado, lo que se complica terriblemente es el
mantinimiento del código cliente de la aplicación en producción, que es la
otra cara de la moneda. Los DBAs que afirmen lo contrario, no se han puesto
en la piel del programador que tiene que mantener el programa cliente, sobre
todo si es un programa en evolución con frecuentes cambios.

Hola Alberto,

On Tue, 22 May 2007 23:22:36 +0200, "Alberto Poblacion"
wrote:

De acuerdo, pero también hay que balancearlo contra el problema
contrario: el abuso de los procedimientos almacenados.

Un problema bastante común y que bastantes personas fomentan.


Saludos

On Tue, 22 May 2007 23:17:15 +0200, "Jesús López"
wrote:

Dios me libre de tener la responsabilidad de administrar una aplicación cuya
seguridad haya sido diseñada por una persona que piense que es lo mismo dar
permiso para eliminar un registro que dar permiso para eliminar todos los
registros de golpe.

Para empezar las aplicaciones no se administran, y no he dicho que sea
lo mismo una cosa que la otra, sino que son igual de inseguras ante
ataques.

A un hacker le da igual tardar toda la noche en borrarte una tabla.

En cambio si un usuario tiene que borrar una tabla por razones
legítimas, se va a acordar de todos los parientes del DBA si le tiene
que dedicar toda una tarde a esa chorrada.

No sólo es una cuestión de seguridad sino de intentar evitar que alguien
inadvertidamente elimine más registros de los que realmente quiere eliminar.

Pues si pasa eso se "deseliminan" y listo. Vaya problema.

Te puede pasar lo mismo o peor si obligas a la gente a eliminar
registros usando bucles.

Hasta el momento, que yo sepa, no hay otra forma de encapsular un SGDB y que
proporcione la misma funcionalidad que los procedimientos almacenados, por
muy primitiva que te parezca.

:-???

Pero si encapsular con procedimientos almacenados precisamente lo que
hace es reducir la funcionalidad.

Es trabajar para tener menos opciones.


Saludos
Alfredo

Alberto,

Yo no estoy diciendo que siempre haya que usar procedimientos almacenados
para todo. Si hay algo que he aprendido a lo largo de los años es que en el
desarrollo de software no hay reglas absolutas, siempre hay excepciones para
todo. Lo que digo es que es recomendable usar procedimientos almacenados
para la mayoría de las cosas.

No me parece mal que instrucciones como SELECT * FROM UnaTabla se manden
directamente desde el cliente, aunque instrucciones como esta habría que
evitarlas a no ser que la tabla tenga poquitos registros y pocos campos. Y
tampoco hay que exagerar con el uso de procedimientos almacenados. Por
ejemplo y llevándolo a un extremo. el siguiente procedimiento me parece una
barbaridad:

CREATE PROCEDURE MiProcedimiento @Campos, @Tabla, @Criterio, @Orden


Sin embargo hay instrucciones sencillas que por las prisas en entregar el
proyecto se hacen mal o se prevee equivocadamente el número de registros que
van a tener. Además los desarrolladores generalmente no son expertos en
optimización de consultas. Por ejemplo:

SELECT <ListaDeCampos> FROM TablaX WHERE LEFT(UnCampo, 5) = @UnParametro

Esta instrucción funcionará bien con pocos registros, pero si hay muchos
será un desastre y no hay manera de evitar una exploración completa de la
tabla sin modificar la instrucción. Si esta instrucción está encapsulada en
un procedimiento almacenado o en una función tabular en línea, dejas la
posibilidad de optimizarla en producción. El DBA puede cambiarla por esta
otra:


SELECT <ListaDeCampos> FROM TablaX WHERE UnCampo LIKE @UnParametro + '%'

Que es prácticamente equivalente. Luego el DBA puede crear un índice con
UnCampo como clave y así acelerar la consulta cientos o miles de veces.


Saludos:

Jesús





"Alberto Poblacion"
escribió en el mensaje news:

"Jesús López" wrote in message
news:

No estoy de acuerdo Alberto. Los procedimientos almacenados no se han
quedado obsoletos y siguen tendiendo ventajas frente a instrucciones SQL
lanzadas por la aplicación por muy sencillas que sean.

Estoy de acuerdo contigo, los procedimientos siguen siendo útiles. Pero
en todos los casos que has mencionado, se trata de procedimientos
especializados que hacen "algo más" que símplemente reflejar una única
sentencia SQL sencilla. La observación que yo hacía es que si símplemente
vas a hacer un "select * from mitabla", no merece la pena meterlo dentro
de un procedimiento almacenado; para eso, lo ejecutas directamente y ya
está. Concedo que en este caso el tráfico de red es ligeramente mayor, ya
que "select * from mitabla" es algo más largo que "exec miproc", pero la
diferencia es insignificante en comparación con el volúmen de los datos
devueltos, que es el mismo en ambos casos. Desde luego, si el "select"
fuera un gigantesco join de una docena de tablas sí que podría merecer la
pena dejarlo dentro de un procedimiento.

Las ventajas de los procedimientos almacenados siguen vigentes y no han
sido superadas en absoluto. Quien haya dicho lo contrario se equivoca de
plano y nunca ha sido DBA ni nunca ha ido a optimizar una aplicación en
producción.

De acuerdo, pero también hay que balancearlo contra el problema
contrario: el abuso de los procedimientos almacenados. Cuando todo,
absolutamente todo, hasta las sentencias más sencillas, se encapsula
dentro de un procedimiento almacenado, lo que se complica terriblemente es
el mantinimiento del código cliente de la aplicación en producción, que es
la otra cara de la moneda. Los DBAs que afirmen lo contrario, no se han
puesto en la piel del programador que tiene que mantener el programa
cliente, sobre todo si es un programa en evolución con frecuentes cambios.

Otro problema bastante común, con bastante peores consecuencias, y que
muchas personas fomentan es el contrario: todas las instrucciones SQL en la
aplícación y ni procedimientos almacenados ni funciones tabulares ni vistas
ni nada.

Saludos:

Jesús

"Alfredo Novoa" escribió en el mensaje
news:

Hola Alberto,

On Tue, 22 May 2007 23:22:36 +0200, "Alberto Poblacion"
wrote:

De acuerdo, pero también hay que balancearlo contra el problema
contrario: el abuso de los procedimientos almacenados.

Un problema bastante común y que bastantes personas fomentan.


Saludos