Procedimientos Almacenados

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.


Saludos

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 :)

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.


Saludos

El Thu, 24 Apr 2008 17:56:20 -0300, Maxi escribió:

Carlos, calmemos un poco las aguas, a ver, yo he simplemente pasado una
serie de referencias pero hay miles mas de paginas como
www.sql-server-performance.com donde 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

Si son tan serios como los anteriores mejor ni te molestes.

La razón por la que es difícil encontrar textos serios que digan
explícitamente que no hay que usar procedimientos almacenados para
ocultarle la estructura relacional a los usuarios es por que es una idea
tan tonta que a ningún verdadero experto en bases de datos se le pasaría
por la cabeza.

Podría preguntar que les parece la idea en un foro serio sobre teoría de
bases de datos, pero francamente me da vergüenza preguntar tal chorrada.

R: Si pero no a los objetos finales sino solo al SP

Las tablas pueden no ser objetos finales, y tus SP si que son objetos
finales por lo que parece.

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 que no son las que tu has dise𠣯

¡Pero que barbaridad!

¿Pero tu donde has estudiado bases de datos?

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

Si la seguridad está bien implementada no te debería de preocupar. Si el
usuario sabe SQL y quiere resolver algún problema a través de la consola
pues perfecto. De hecho es algo que los usuarios avanzados (como por
ejemplo los compañeros de soporte) solicitan a menudo.

Te imaginas los problemas de esto no?

A mi esto no me causa ningún problema. ¡No me digas que a ti si!

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.

Pero hombre, también se pueden crear reglas para las inserciones en tablas,
y el SGBD asegurará la regla no importa desde donde mandes el insert. Por
ejemplo puedes crear una clave primaria para que no se puedan insertar
registros duplicados desde ningún sitio.

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

Vaya, impresionante reutilización. Pero yo ya consigo "abstraerme" aun más
con:

String.Format("select * from {0}", s);

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

UI -BI - DAL - DataBase

Yo prefiero estas capas:

A - UAM - BA - BULUBA - BALAM - BAMBU

Los Store procedure te ayudan mucho porque desde tu DAL solamente haces un
llamado a una caja negra y es menos acoplable. Si queres reutilizar ese SP
lo podes hacer de N aplicaciones en N lenguajes de programacion. Ahora bien
vos a que solucion de modelo hablas? aca estamos hablando de programacion y
de arquitectura de aplicaciones no me queda claro que solucion no te da el
SP al modelo.

Bueno, esto ya está llegando a niveles surrealistas.

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.

Parece que no te has molestado ni en leer tus propios enlaces que
desmienten la ventaja de los SP en este aspecto. Es más parece que no haces
el menor caso a nada de lo que se te dice.

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. Es cierto que la logica de negocios puede ir fuera y eso no esta mal,
pero si la pones en un SP estas centralizandola.

¿O sea que si creamos una PK o una FK o un CHECK no estamos centralizando
la lógica de negocio?

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.

¿Y los procedimientos almacenados no se ejecutan dentro de una transacción?

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

Son muy malos.


Saludos

Hola, creo que estamos en algunos problemas de conceptos.

A ver, las reglas de integridad estan en estos SGBD de los que hablo, solo
le falta la parte de programacion.

En la definicion de un sistema de base de datos relacional no indica que
debe tener Store Procedures, indica que debe controlar integridad.

http://www.pcmag.com/encyclopedia_t...mp;,00.asp

Dime por favor donde has leido (link) que un SBDB no es tal si no dispone de
Store Procedures


Microsoft MVP SQLServer
www.sqltotalconsulting.com
-

"Alfredo Novoa" escribió en el mensaje de
noticias:

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.


Saludos