Acceso a Datos (Mejores practicas)

La base de datos es parte de la aplicación y se adminsitra digas lo que
digas.

Cuanto más difícil se lo pogas al hacker y más trabajo le cueste mucho
mejor.

Si el usuario tiene la necesidad de eliminar un conjunto de registros a la
vez, debería haber una forma en la aplicación para que lo pueda hacer
fácilmente. Por ejemplo un procedimiento almacenado.






"Alfredo Novoa" escribió en el mensaje
news:

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

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

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.

Si usas compresión la diferencia será aun menor, y por ejemplo el
equivalente en D4 de "select * from mitabla" es "mitabla".

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.

Yo creo que mejor en una vista.

Igual que hay mucho abuso de procedimientos almacenados también es
bastante habitual la infrautilización de las vistas.


Saludos

On Wed, 23 May 2007 14:25:43 +0200, "Jesús López"
wrote:

Yo no estoy diciendo que siempre haya que usar procedimientos almacenados
para todo.

Pues es lo que parece. Es justo lo que Alberto y yo estamos
criticando.

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.

Esto es una regla absoluta y por lo tanto una contradicción y por lo
tanto una falsedad :-)


Saludos

Alberto critica con argurmentos, tú simplemente dices que sí o que no.

Por lo demás sin comentarios.


"Alfredo Novoa" escribió en el mensaje
news:

On Wed, 23 May 2007 14:25:43 +0200, "Jesús López"
wrote:

Yo no estoy diciendo que siempre haya que usar procedimientos almacenados
para todo.

Pues es lo que parece. Es justo lo que Alberto y yo estamos
criticando.

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.

Esto es una regla absoluta y por lo tanto una contradicción y por lo
tanto una falsedad :-)


Saludos

On Wed, 23 May 2007 14:35:41 +0200, "Jesús López"
wrote:

La base de datos es parte de la aplicación y se adminsitra digas lo que
digas.

La base de datos es parte del sistema y no de la aplicación y claro
que se administra. Las aplicaciones son otras partes del sistema.

Cuanto más difícil se lo pogas al hacker y más trabajo le cueste mucho
mejor.

Siempre que no se lo pongas también más difícil a los legítimos
usuarios del SGBD (como los programadores), y eso es lo que casi
siempre pasa cuando se encapsula la base de datos usando SP
indiscriminadamente.

No me parece buena idea atarles las manos a tus usuarios para ver si
desanimas a fantasmas.

Si tenemos acceso directo a media docena de tablas, el número de cosas
que podemos hacer con ellas es inmenso: cualquier combinación de
juntar, restringir, unir, proyectar, restar conjuntos, agrupar, etc,
etc).

Si tenemos acceso a una docena de SP el número de cosas que podemos
hacer es 12.

Es mucho peor que encapsular una interfaz en C# con una en
ensamblador.

Si el usuario tiene la necesidad de eliminar un conjunto de registros a la
vez, debería haber una forma en la aplicación para que lo pueda hacer
fácilmente. Por ejemplo un procedimiento almacenado.

En los usuarios de la base de datos incluyo a los programadores.

Es decir que cada vez que queremos hacer algo que no está
predeterminado en los SP tenemos que encargarle al DBA que cree uno
nuevo y mientras tanto estamos parados.

Esto es una pesadilla para el mantenimiento y al final acabamos con
miles y miles de líneas de procedimientos almacenados que hay que
mantener y no aportan valor (los SP justificados si aportan valor,
pero los superfluos no).

Por ejemplo en lugar de construir una consulta dinámica para crear un
informe complejo tendríamos que crear montones de SP con todas las
combinaciones.


Saludos
Alfredo