Las famosas n capas.

excepto por si el día de mañana tienes
que hacer una migración a un sistema que no soporte los procedimientos

De ahi la importancia de una buena capa de acceso a datos, que tampoco
parece gustarle a Alfredo. Esta capa le da una abstraccion a la capa de
negocio sobre el sitio de almacenamiento de los datos. Si te cambias a un
sistema que no soporte los procedimientos, solo modificas esta capa, y en
ella los simulas si es necesario, sin necesidad de cambiar nada en la capa
de negocio ni presentacion ya que a ellas realmente no les importa donde es
que estan guardados los datos.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo
https://mvp.support.microsoft.com/p...4EF5A4191C

Por supuesto, Eduardo. Yo me estaba limitando a las ventajas (muchas) e
inconvenientes (muy pocos) de los procedimientos almacenados.


Un saludo

-
"Sólo sé que no sé nada. " (Sócrates)

"Eduardo A. Morcillo [MS MVP VB]" <emorcillo .AT. mvps.org> escribió en el
mensaje news:

> excepto por si el día de mañana tienes
> que hacer una migración a un sistema que no soporte los procedimientos

De ahi la importancia de una buena capa de acceso a datos, que tampoco
parece gustarle a Alfredo. Esta capa le da una abstraccion a la capa de
negocio sobre el sitio de almacenamiento de los datos. Si te cambias a un
sistema que no soporte los procedimientos, solo modificas esta capa, y en
ella los simulas si es necesario, sin necesidad de cambiar nada en la capa
de negocio ni presentacion ya que a ellas realmente no les importa donde

es

que estan guardados los datos.

Eduardo A. Morcillo [MS MVP VB]
http://www.mvps.org/emorcillo

https://mvp.support.microsoft.com/p...104EF5A419
1C

On Tue, 12 Apr 2005 16:40:57 +0200, "Carlos Sacristán"
<csacristanARROBAmvpsPUNTOorg> wrote:

Por supuesto. Las tablas son lo único a lo que necesitas acceder, esto
es uno de los principios básicos del Modelo Relational. A esto se le
llama el Principio de Información de Codd.

a un modelo E/R

Supongo que querrás decir a un modelo relacional, por que los modelos
E/R no tienen nada que ver con lo que estamos hablando.

, pero estamos hablando de la aplicación prácticas de este
modelo, y desde luego las tablas es elemento básico, pero no suficiente para
implementar una buena aplicación

Vamos a ver. Un diseño de base de datos relacional de una empresa
concreta es una aplicación práctica del Modelo Relacional de Codd, y
es de lo que estamos hablando.

El Principio de Información nos dice que las tablas son todo lo que
necesitamos conocer de una base de datos para gestionarla.

Claro que si. La seguridad no tiene nada que ver con si accedemos
directamente a las tablas o no,

directamente a las tablas (con las consecuencias que eso puede tener) que
acceder a ellas de la forma y como uno quiera a través de los procedimientos

Pero es que se pueden dar permisos de la forma que uno quiera, y por
eso no hace falta utilizar procedimientos almacenados. Para esto está
el mecanismo de seguridad del SGBD.

pero el rendimiento y el mantenimiento
son mejores (sobre todo el mantenimiento) si accedemos directamente a
las tablas.

Para que la consulta esté compilada no se necesitan utilizar
procedimientos almacenados, se pueden utilizar vistas y también se le
puede pedir al SGBD que precompile las consultas desde la aplicación
utilizando la instrucción "Prepare".

Por lo pronto nos ahorramos todo el desarrollo de
procedimientos almacenados que no sirven para nada.

Imagínate que cambiamos, por la razón que sea, el diseño de una tabla.

¿El diseño de una tabla física o de una tabla lógica?

Según
tu opinión, es más mantenible tener que cambiar la sentencia

No, en ningún caso es necesario cambiar la sentencia. Si cambiamos el
diseño físico de una tabla, el diseño lógico que es el que las
aplicaciones ven no tiene por que cambiar.

Si cambiamos el diseño lógico de la base de datos podemos crear una
vista externa de la base de datos que sea igual al diseño de base de
datos anterior, con lo que todas las aplicaciones seguirán funcionando
correctamente.

En resumen, que para conseguir un fácil mantenimiento con lo que hay
que jugar es con las vistas y con los permisos, y no con los
procedimientos almacenados. Esto es algo muy básico en teoría de bases
de datos.

Sinceramente, no entiendo por qué tienes tantos reparos en usar
procedimientos almacenados.

Por una razón fundamental, por que cuesta trabajo crearlos, por eso
solo los uso cuando realmente hacen falta, que es cuando las cosas no
se pueden hacer de una forma más fácil.

Si tienes varios cientos de tablas vas a tardar un montón de tiempo en
crear todos los procedimientos necesarios para todas las formas
posibles de acceder al SGBD. Cuando necesites una nueva funcionalidad
tendrás que volver a crear nuevos procedimientos almacenados, y cuando
dejes de necesitarla te quedarán procedimientos almacenados inútiles.
Este tipo de cosas son precisamente las que hacen dificil el
mantenimiento.

Si usamos SQL directamente es todo mucho más sencillo, podemos hacer
cualquier cosa con la base de datos con un esfuerzo mínimo. Como es
bien sabido los lenguajes declarativos son mucho más potentes que los
procedimentales. Si construimos una interfaz procedimental encima de
un interfaz declarativo (SQL) estamos dando un gran paso atrás en
flexibilidad, y por eso siempre tendremos que estar haciendo
modificaciones al interfaz procedimental.

excepto por si el día de mañana tienes que hacer una
migración a un sistema que no soporte los procedimientos

Eso no lo deberíamos hacer nunca. Los procedimientos almacenados a
veces son imprescindibles, y un sistema que no los soporte es
sencillamente impresentable. Hasta MySQL que es de lo peorcito en SGBD
los soporta.


Saludos

On Tue, 12 Apr 2005 12:10:46 -0300, "Eduardo A. Morcillo [MS MVP VB]"
<emorcillo .AT. mvps.org> wrote:

De ahi la importancia de una buena capa de acceso a datos,

Intenta definir que es una capa de acceso a datos.

que tampoco
parece gustarle a Alfredo.

Ni un pelo, es un concepto que no tiene ni pies ni cabeza.

Esta capa le da una abstraccion a la capa de
negocio sobre el sitio de almacenamiento de los datos.

Las aplicaciones nunca deben de acceder directamente al sitio de
almacenamiento de los datos, se debe de utilizar una capa intermedia
que se llama SGBD. El SGBD proporciona toda la abstracción necesaria
sobre la base de datos.

Si te cambias a un
sistema que no soporte los procedimientos, solo modificas esta capa, y en
ella los simulas si es necesario, sin necesidad de cambiar nada en la capa
de negocio ni presentacion ya que a ellas realmente no les importa donde es
que estan guardados los datos.

Ya, y si dejamos los ordenadores y volvemos a hacer las cosas con
lápiz y papel tampoco necesitamos cambiar nada en la aplicaciones :)

Los procedimientos almacenados están dentro de lo mínimo exigible a un
SGBD. Si una cosa no soporta procedimientos almacenados esa cosa no es
un SGBD.


Saludos

On Tue, 12 Apr 2005 11:55:29 -0300, "Eduardo A. Morcillo [MS MVP VB]"
<emorcillo .AT. mvps.org> wrote:

Con respecto al mantenimiento, con un SP tienes centralizado el acceso a los
datos con lo cual si algo cambia en la BD no tienes que ir a cambiar varias
sentencias SQL distribuidas por todo tu codigo sino que solo cambias el SP.

Esto ya se lo he explicado a Carlos. Si algo cambia en el esquema
físico de la BD las aplicaciones simplemente no se van a enterar. A
esto se le llama independencia física.

Si cambias el esquema lógico puedes hacerlo creando un nuevo esquema y
dejando el esquema viejo intacto, con lo que las aplicaciones viejas
tampoco se van a enterar. Esto se llama independencia lógica.

La independencia física y la independencia lógica son dos de las
características fundamentales del Modelo Relacional.

Con respecto al rendimiento, un SP esta compilado y el servidor ya tiene un
plan de ejecucion preparado. En cambio si ejecutas sentencias directamente,
estas tienen que primero ser parseadas y chequearse por errores y luego
crearse el plan de ejecucion para ejecutarlas. Todo eso te lleva a perder
rendimiento.

Esto también se lo he explicado a Carlos. Eso lo solucionas usando
vistas o usando la instrucción Prepare desde las aplicaciones.

Y con respecto a seguridad, es mejor que el usuario que usa el sistema no
puede acceder directamente a las tablas y solo pueda ejecutar SPs que
acceden a ellas. Ademas de esta forma el mantenimiento de la seguridad es
mucho mas simple que estar seteando que acceso tiene cada usuario a cada
tabla.

Es todo lo contrario, es muchísimo más complicado. Los mecanismos de
seguridad de los SGBD están precisamente para resolver estas cosas, y
no los procedimientos almacenados.


Saludos