Procedimientos Almacenados

El Thu, 24 Apr 2008 14:43:19 -0700 (PDT), Carlos M. Calvelo escribió:

Va a ser mejor pasarse a este tema porque acabo de
leer el último mesage de Maxi, y cada vez aparecen mas
temas en los que vamos a estar muy en desacuerdo.
Ya casi no me atrevo :)

¿Quieres decir que es mejor pasar del tema por las cosas tan raras que dice
Maxi de los patrones para hacer capas y las cajas negras que se acoplan y
todo eso? :-)

http://www.historiaviva.org/vestime...anto.shtml

Para que luego digan que no pongo enlaces :-)



Saludos

Hola, es bueno no coincidir :-) pero yo no pretendo que coincidas sino que
ustedes me han dicho que mis argumentos no son validos , yo digo que si son
validos y tengo como demostrarlo (lo hice por medio de aqui en lineas). Esto
no quiere decir que uses Store, quizas no quieres, quizas no puedes ,
quizas.. Pero una cosa no quita la otra, mis argumentos de las ventajas del
uso de SP son validos. Para demostrar ello ahora si te voy a pasar unos
links mas interesantes y "serios" ya que no solo son de Microsoft sino
tambien de IBM. Espero los leas ;-)

http://www.sql-server-performance.c...es_p1.aspx

http://www.redbooks.ibm.com/redbook...247083.pdf

http://blog.sqlauthority.com/2007/0...advantage/

http://www.sommarskog.se/dyn-search.html

http://msdn2.microsoft.com/en-us/li...78510.aspx

En todos estos links hablan de las mismas ventajas que yo hable a lo largo
de todo este hilo. Ahora bien, si todas estas personas y empresas estan
erradas seria bueno un documento que ustedes pasen que contradiga todo esto.

Este es un lindo tema lastima que por aca se hace pesado de escribir, si les
interesa podemos armar un chat entre los tres y discutir, pero antes lean
los documentos porque vamos a empezar medio mal sino :-s

Mi msn es el siguiente: Maxi_adrogue(arroba)msn(punto)com

Me agregan y coordinamos un chat :-)

Saludos a los dos


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Carlos M. Calvelo" escribió en el mensaje de
noticias:

On 24 apr, 23:34, Alfredo Novoa wrote:

El Thu, 24 Apr 2008 23:16:54 +0200, Alfredo Novoa escribió:

> El Thu, 24 Apr 2008 13:55:22 -0700 (PDT), Carlos M. Calvelo escribió:

>> On 24 apr, 22:18, "Carlos M. Calvelo" wrote:
>>> Y eso con mucha mas
>>> granulidad ...

>> Ui! Que patada! No será *granulación*? :)

> Sería "granularidad".

Pos no, granularidad no viene en el diccionario, es granulación.

<Broma>
Eso te pasa por listo! ;)
Va a ser mejor pasarse a este tema porque acabo de
leer el último mesage de Maxi, y cada vez aparecen mas
temas en los que vamos a estar muy en desacuerdo.
Ya casi no me atrevo :)
</Broma>

Saludos,
Carlos

pd: Alfredo, el <Broma></Broma> es XML :)

On 24 abr, 18:15, Alfredo Novoa wrote:

El Thu, 24 Apr 2008 17:58:01 -0300, Maxi escribió:

> Hay motores relacionales que hasta hace algunas versiones no tenian Stores
> Procedures ;-)

Si una cosa no tiene SP entonces no es un SGBD.

Lo de "motor" es un término poco técnico que suele incluir a los primitivos
procesadores de archivos como el DBase, PICK y otros engendros de la
antigüedad.

Saludos

MySQL, no tenia SP hasta la version 5, recien a partir de esa version
la implemento
saludos

Hola Maxi,

On Apr 24, 10:56 pm, "Maxi" wrote:

Carlos, calmemos un poco las aguas,

Yo estoy muy calmado :)

a ver, yo he simplemente pasado una
serie de referencias pero hay miles mas de paginas comowww.sql-server-performance.comdonde podras encontrar varios articulos de
arquitectura y buenas practicas, tambien puedes revisar los documentos de
arquitectura de Microsoft en su pagina. Solo expuse algunos links si quieres
busco mas y seran tan serios como los anteriores, tu solamente me has
indicado un libro, yo quiero que me indiques un link donde diga: El uso de
SP no ayuda a la seguridad, no ayuda a la centralizacion no ayuda a la
performance. Quiero leer eso porque es lo que estamos discutiendo
basicamente, yo no digo que siempre hay que usarlos, pero digo que tienen
ventajas enormes usarlos y enumere los items donde las tienen.

Yo no me trago todo lo que leo. Ni voy a darte un link donde puedas
leer eso. Si quieres me monto yo una página web, lo pongo allí y tu
lo lees. :)

Yo no me trago cualquier cosa como buena práctica ni dejo que 'las
autoridades' decidan por mi lo que es una buena arquitectura. Leo
y determino, dentro de mis posibilidades, lo que creo que vale la
pena. Voy acumulando así cierta visión de las cosas y voy
determinando qué autores vale la pena tomar en en serio y cuales no.
De los que tomo en serio no me trago tampoco todo sino que evaluaré
todo lo que proponen según mi nivel en ese momento.

Ahora voy a
ir linea por linea de tus comentarios a reponderte :-) porque considero que
todo suma.
Disculpame no me has ofendido

No problem!

y tienes razon, tomemos esto como debe ser y
es una discusion entre 2 profesionales de forma tecnica :-)

Vamos a los puntos.

Entonces si es necesario. Hay que darle acceso; o sea permiso de
ejecución.

R: Si pero no a los objetos finales sino solo al SP y no importa donde este
SP haga la llamada ni a cuantos objetos, solo le das acceso al SP y nada
mas, entonces por ejemplo te aseguras que siempre hagan por ejemplo la
insercion de tu factura por medio del SP y no por ejemplo por medio de un
access, excel o cualquier otro sitio. Si cambias algo de logica lo haces en
el SP y la llamada puede hasta ser la misma, imaginate que el proceso ahora
requiere hacer una verificacion o bien guardar en otra tabla algo, eso lo
programas en el SP y desde tu aplicacion es transparente.

Aquí repites lo que ya has dicho antes. No voy a repetir mi
respuesta porque estamos dando vueltas en el mismo círculo.

>Y eso qué ventaja tiene?
>Las ventajas que tu has dado (tu mismo y en links) no son ventajas
>específicas de SP's, sino que también se puede decir de tablas base
>y de vistas.

bueno aca hay uno de los puntos, si este punto no se comprende entonces no
podemos hablar de ventajas de los SP.
Tu no deberias permitir que los usuarios hagan insert sobre las tablas de
forma directa, de hecho ni las deberian conocer, es una cuestion de que
puedas controlar de donde y como se hace y que ademas las tablas no sean
accedidas de aplicaciones

Espero que no te sientas ofendido, porque no te estoy calificando a
ti sino lo que has puesto aquí arriba. Tengo que darle la razón
a Alfredo; es mas lo repito con ahínco: "Esto es una barbaridad!"
(A las cosas hay que llamarlas por su nombre.)

que no son las que tu has diseñado, imafginate un
soft de gestion donde tienes una tabla clientes, bien, si desde tu
aplicacion usas Select o insert el usuario que se conecta desde la misma
debe tener permisos sobre la tabla, ahora bien tu al darle permisos sobre la
tabla ese usuario puede hacer uso de ella desde cualquier otro lado, por
ejemplo un excel, una aplicacion que a el se le ocurra desarrollar etc, con
lo cual puede estar haciendo operaciones en tu sistema de forma externa y no
controlada por ti. Te imaginas los problemas de esto no?

No, no me los imagino. No determina la aplicación lo que puede hacer
un usuario con una tabla sino el SGBD.

>La aplicación puede entrar de formas desconcidas para el usuario
>en la bbdd. El mismo usuario puede tener un login própio para
>utilizar con otras herramientas. Aunque si el sistema de seguridad
>está bien diseñado no veo ninguna ventaja en ello.
>Con lo de los roles me estoy refiriendo a los roles en la bbdd.
>En definitiva.. se puede uno montar muchos esquemas de seguridad
>distintos.

Como en forma desconocida? tu deberias tener por cada usuario de tu
aplicacion un login en el SQL para poder controlar la seguridad y ademas
monitorear, hacer auditorias, etc. Si usas un usuario generico estamos
hablando de otro esquema de sistemas y por lo general son ambientes Web.

>Y no es eso lo mismo que que entre y que pueda hacer
>un 'execute insert_proc'?

No porque si por ejemplo en el SP de insert tu has definido alguna regla se
ejecutara no importa de donde lo llames que siempre hara lo mismo. Ademas
hasta podrias el dia de mañana cambiar algo en el proceso de insert y solo
tocas el SP (si es que no cambian los param de entrada claro)

"Siempre hará lo mismo" no es una ventaja. Y las reglas de integridad
también se pueden poner sobre la tabla para determinar lo que puede
hacer con ella. (no ves que andamos en círculos?)

>El código de las queries (o el de las llamadas a procedimentos
>almacenados) es la interfaz entre aplicaciones y el SGBD.
>En cuanto a 'la capa de acceso a datos' creía yo que estaba esta
>en el SGBD.
>Yo le digo al SGBD 'SELECT Esto FROM LoOtro WHERE EstoOtro' y el
>SGBD 'accede a los datos' (a este nivel no me interesa como) y me
>los devuelve.

Bueno aca hay un error de conceptos,

Eso es algo seguro! :)

la capa de acceso a datos es la que se
encarga de interactuar con la capa de datos (esta si es la base en si), en
la capa de acceso a datos te puede conectar con la capa de datos via Select
o via Stores.

Lo que si te interesa que si vos tenes un select * from clientes y lo usas
en mas de un modulo o en mas de una aplicacion, si armas un SP lo podes
reutilizar en cualquier aplicacion en cualquier sitio y no te interesa como
programador que haga ese SP solo lo llamas, con lo cual te abstraes aun mas.

A mi no me interesa cuantos programadores ni desde cuantas
aplicaciones hagan ese select. Solo me interesa que sea cual sea la
forma que tenga el select/insert/update/delete, siempre se cumpla
con las reglas de integridad.

>Yo no digo que sean o no sean parte del modelo relacional. Digo que
>no son parte de la solución al problema que trata de solucionar el
>modelo. Esconder la estructura de la base de datos y un lenguaje
>relacional detrás de una biblioteca de procedimientos no es la
>solución.

A ver, tu deberias manejar un patron denominado Capas ok, seria la forma
correcta de hacer una aplicacion, entonces aqui tiene

OK!

UI -BI - DAL - DataBase

Esto es una tontería que desgraciadamente está muy extendida. En un
sistema tenemos Aplicaciones y Servidor. Aplicaciones pueden ser
muchas y el Servidor (SGBD) puede representar una base de datos
distribuida por toda la organización o hasta fuera de ella. Estas
son dos capas lógicas.

Ahora cada una de estas dos capas puedes dividirlas en todas las
capas físicas que tu quieras, pero el 'acceso a datos' pertenece al
lado del SGBD. En cuanto al business layer (supongo que eso quieres
decir con 'BI') será para implementar 'business rules'. Este es un
término que si se analiza bien, lo que realmente significa viene a
no ser más que 'reglas de integridad de datos'. Esta capa física es
también responsabilidad del SGBD.

Al lado del las Aplicaciones solo queda el UI (user interface)
entonces, y al lado del servidor solo queda el SGBD que es el
responsable de 'la integridad' (BI) y debajo de esto el 'acceso a
datos'. La integridad la definimos con 'integrity constraints' y
del acceso a datos no nos temenos que preocupar para nada, aparte
de a nivel físico tratar de elevar la eficiencia de cierto tipo de
consultas (a veces a costa de otras) con ciertos mecanismos,
como por ejemplo índices.

Los Store procedure te ayudan mucho porque desde tu DAL solamente haces un
llamado a una caja negra y es menos acoplable.

Un select * ... no es un 'acceso a datos'. Es una interfaz de mucho
mayor nivel de abstracción que cualquier procedimiento (me repito otra
vez!)

Por qué insistes en llamarle a eso 'acceso a datos' y a una llamada
a un procedimiento que es mucho mas limitado y solo hace lo mismo
para un pequeño número de casos, no le llamas lo mismo?

Si queres reutilizar ese SP
lo podes hacer de N aplicaciones en N lenguajes de programacion.

Si quieres reutilizar un select * ... de mil maneras distintas lo
puedes hacer desde N+M aplicaciones y desde N+M lenguages de
programación. :)

Ahora bien
vos a que solucion de modelo hablas? aca estamos hablando de programacion y
de arquitectura de aplicaciones.

Arquitectura de 'systemas'. Busca información sobre la arquitectura
ANSI-SPARC. En el libro de Date (yo tengo la edición 8) viene una
buena introducción, creo que el segundo capítulo.

no me queda claro que solucion no te da el
SP al modelo.

>Pues el que utiliza SQL Server para eso.
>Por cierto son las consultas en el SP las que tienen planes de
>ejecución no el SP mismo. El plan de ejecución del SP lo programmo
>yo diciendole: 'primero haces esto, después si esto es verdad
>haces esto otro y si no repites esta otra cosa X veces'.

Esto si no te lo comprendo, yo estoy hablando del plan de ejecucion interno
de SQL por toda query que uno realiza, el evalua cual es el mejor camino a
realizar (que indices usar, como usarlos etc) Este calculo SQL lo hace por
cada ejecucion, en un SP ese calculo queda compilado y no debe calcularlo
siempre.

Como bien dices 'por toda query'! El plan es por query, no por SP.
Porque todo el mundo hable de planes para SP's habrá que seguir
pensando cada uno por si mismo, y tratar de saber que es lo que se
está diciendo exactamente.

>Para 'verificar cosas' tenemos los constraints. Y cuando estos
>no den mas de sí, los triggers.

Si claro, primero hay que tener un bien diseño con sus constraint. Pero los
trigger no son siempre utiles para hacer verificaciones, por ejemplo debes
saber que si correc un proceso BCP o DTS los trigger se deshabilitan por
default con lo cual si has puesto logica ahi puedes estar en problemas.

Pues muy mal por los DTS!

Otro de los lugares donde se pone logica o verificaciones en el los Store
Procedures, entonces si tenemos un SP de grabar factura y antes de eso hay
que verificar si el cliente tiene credito por ejemplo, lo puedes poner en el
SP.

Y lo puedes poner en un check, o en un trigger. Entonces para eso no
hace falta denegar acceso a la tabla.

Es cierto que la logica de negocios puede ir fuera y eso no esta mal,

Si que está mal! Debe ir con la bbdd y el SGBD es el que debe
asegurar que se cumpla esa lógica (integridad de datos!).

pero si la pones en un SP estas centralizandola.

y en check o trigger también.

En los triggers tambien se suele poner logica de negocios, pero como veras
no es una cosa si y la otra no, pueden ser ambas, yo por lo general lo
prefiero en los SP porque el trigger esta dentro de una transaccion y si me
pongo ahi a aplicar logica voy a tener transacciones mas largas y por ende
mayores bloqueos que hasta pueden derivar en un interbloqueo.

Todo lo que lógicamente tengas que hacer en una transación no es menos
por ponerlo en un SP.

>Además nadie está diciendo (yo no por lo menos) que no tenga ninguna
>aplicación los SP's. Pero el esconder la estructura de los datos
>de las aplicaciones y los usuarios no es una de ellas.

Bueno como que no, es una forma de abstraccion y de seguridad para que nadie
acceda de forma directa a los objetos.

Estos *objetos* son una estructura lógica que es (debe ser) pública
en la organización. (Dependiendo que la seguridad y identidad de cada
uno claro!)

Tambien comente otros factores,
reutilizacion, administracion, etc.

Toda la estructura es 'reutilizable', etc.

Hasta analisis de problemas, imaginate que tu servidor de base de datos
tiene problemas de performance, entonces se puede para ver las causas
analizar los procesos, se puede montar un profiler y ademas un performance
monitor, pero si tenemos SP hasta podriamos verificar si hay malas practicas
en ellos con el Best Practice Analyzer de Microsoft.

Bueno no creo que llegemos a un punto en comun pero si me gustaria aclarar
algunos conceptos.

No vamos a llegar a ese punto común Maxi. Con este último mensage
tuyo nos hemos separado mas. Ya estamos muy en desacuerdo sobre lo
que es una base de datos y un sgbd; pero ahora nos hemos salido
a la arquitectura del sistema y las diferencias son abismales en
cuanto a conceptos. Y (obviamente) yo creo, sé :), que eres tu
el que está equivocado.

Saludos

Te recomiendo los doc de arquitectura en capas de Microsoft, son muy buenos
y tambien estan en español :-)

Lo que pienso sobre esas capas ya lo comenté arriba. He sido miembro
el el pasado de un equipo (con gente y empresas de tres países
en Europa) que ha desarrollado un enorme projecto con esas ideas.
Estoy hablando de ya antes del 2000. No te lo puedo demostrar a tí
(ni a nadie) que así sea claro, pero yo sé ahora con total seguridad
que esa ha sido la causa de que resultó en un desastre total. Pero
bueno esa es una experiencia personal, y en esta discusión solo una
anécdota.

Saludos,
Carlos

Hola Alfredo,

On 24 apr, 23:52, Alfredo Novoa wrote:

El Thu, 24 Apr 2008 23:15:45 +0200, Alfredo Novoa escribió:

> El Thu, 24 Apr 2008 17:58:01 -0300, Maxi escribió:

>> Hay motores relacionales que hasta hace algunas versiones no tenian Stores
>> Procedures ;-)

> Si una cosa no tiene SP entonces no es un SGBD.

Lo que quiero decir es que un SGBD tiene que ser computacionalmente
completo para poder garantizar cualquier posible regla de integridad.

Y para eso necesitamos poder recurrir a la programación procedimental para
programar así lo que no podamos resolver de forma declarativa.

Yo, como Maxi, no consideraba SP's parte del modelo.
Gracias por estas aclaraciones. Sobre sobre esta última
lo hace bastante plausible. Vamos, que entiendo que
las funciones, los triggers y los procedimientos almacenados
cubren esa necesidad.
Pero seguiré profundizando en TTM para convencerme a
mi mismo.

Saludos,
Carlos