Procedimientos Almacenados

El Fri, 25 Apr 2008 19:03:43 -0300, Maxi Accotto escribió:

Mmm BL = businnes rules eso en español

¿Será Business Lules, no? :-)

significa (Regla de negocios y no
regla de datos) Viendo todo tu texto creo que hay confusion entre una regla
de datos o integridad y una regla de negocios.
Ejemplos de BL: Para poder vender este producto el cliente no debe tener
una mora
No se permiten pedidos de clientes que tengan
deudas
No se puede hacer una venta de un producto si
no hay en inventario

Supongo que sabrás que los genios de las capas de Patterns & Practices
dicen que esas reglas las tienen que asegurar las aplicaciones :-((((

Pa matarlos :-)

A ver el SP guarda el plan precompilado amigo, te has leido los libros
online sobre la arquitectura de Store Procedures? te recomiendo una leida
asi ves como funciona.

¿Pero te los has leido tu?

Te he dado referencias que dicen que con las consultas también se guardan
los planes en la caché. Incluso también lo decía un enlace que me diste tu
mismo.

¿Nos quieres trolear?

Estasmos hablando de cosas distintas, tu hablas de reglas de integridad y yo
de negocios, las de integridad ya te dije que coincido contigo, pero las de
negocio pueden estar dentro o fuera de la bdd, si estan dentro para hacerlas
podes o usar trigger o Store, si usas trigger haras que las transacciones
duren mas y tengas mas bloqueos, imaginate si por cada factura a grabar hay
que verificar si el cliente tiene saldo deudor y de ser asi no permitir
grabar la factura, si comprobas durante una transaccion (como es el caso del
trigger) tus bloqueos aumentan de forma innecesaria haciendo el sistema mas
lento entre otros tantos problemas

¿Quieres decir que estás a favor de comprobar reglas de negocio en las
aplicaciones por que así se puede reducir la duración de las transacciones?

¡Ay mi madre!

Esto va cada vez a peor.

Creo que en muchas cosas estamos hablando de lo mismo pero sin
interpretarnos,

Pues yo creo que cuanto más te interpreto más me asusto :-)



Saludos

Ya me canse de leer un hilo tan largo y repetitivo. Aparte poco conclusivo.

Creo que una de las ventajas de los procedimientos almacenados que han
olvidado mencionar, es que se pueden reutilizar en distintos lenguajes de
programación, a que me refiero con eso, a que no debo de escribir la misma
secuencia de comandos, en visual studio .net, java, visual foxpro, php,
etc con que lo haga una vez en el lenguaje nativo de sql de la base de
datos es mas que suficiente. Creo que eso no es discutible. Yo los he
utilizado en muchas de mis aplicaciones y en muchas otras los he evitado,
dependiendo para que vaya enfocada la aplicación y la cantidad y velocidad
de datos a almacenar, ya que si deseo almacenar rapidamente archivos
externos con datos en una bd puede o no ser eficiente el utilizar
procedimientos almacenados. Esto también depende del motor de base de datos.
Si tengo que tomar un string que contiene varios campos de distintas tablas,
puede que me convenga hacer un procedimiento almacenado, ya que si falla la
insercion de alguno de los datos, puede hacerse un rollback para que no
quede incompleta la captura de todos los registros del dato que se quiere
insertar. Aunque con esto no quiero decir que uno sea mejor que el otro
procedimiento siempre, todo depende que se desee hacer.


Lic. J. Enrique Ramos Menchaca
Guadalajara, Jalisco, Méxiico.

"Oscar" escribió en el mensaje de
noticias:

Buenas:

Tengo un procedimiento almacenado que realiza la insercion,
actualizacion o el borrado segun un parametro.

ahora bien, la discusion que se generó en la empresa es si un solo
procedimiento almacenado con esas caracteristicas es mas lento o no
que generar tres procedimientos almacenados por separado segun la
accion, o sea un PA para insercion un PA para actualizacion y un PA
para borrado, debido a que de esta forma se esta SQL lo optimiza
mejor.

Gracias

Hola J. Enrique:

"J. Enrique Ramos Menchaca" <jermmxNO? escribió en el
mensaje news:

Ya me canse de leer un hilo tan largo y repetitivo. Aparte poco
conclusivo.

Creo que una de las ventajas de los procedimientos almacenados que han
olvidado mencionar, es que se pueden reutilizar en distintos lenguajes de
programación, a que me refiero con eso, a que no debo de escribir la misma
secuencia de comandos, en visual studio .net, java, visual foxpro, php,
etc con que lo haga una vez en el lenguaje nativo de sql de la base de
datos es mas que suficiente. Creo que eso no es discutible.

Esto por sí solo no es una razón concluyente, a mi entender. Al final, en
cada uno de los lenguajes vas a tener que llamar al procedimiento almacenado
con código propio del lenguaje. Es decir, en un caso básico de un insert,
cambio el código SQL que hace un insert into con una serie de argumentos que
serían los valores a insertar, por un procedimiento almacenado que va a
recoger más o menos lo mismo.
Cada lenguaje tiene un código propio para hacer eso, con lo cual no es mucha
la diferencia

Yo los he utilizado en muchas de mis aplicaciones y en muchas otras los he
evitado, dependiendo para que vaya enfocada la aplicación y la cantidad y
velocidad de datos a almacenar, ya que si deseo almacenar rapidamente
archivos externos con datos en una bd puede o no ser eficiente el utilizar
procedimientos almacenados. Esto también depende del motor de base de
datos. Si tengo que tomar un string que contiene varios campos de
distintas tablas, puede que me convenga hacer un procedimiento almacenado,
ya que si falla la insercion de alguno de los datos, puede hacerse un
rollback para que no quede incompleta la captura de todos los registros
del dato que se quiere insertar. Aunque con esto no quiero decir que uno
sea mejor que el otro procedimiento siempre, todo depende que se desee
hacer.

Esto es un caso diferente, ya que si le vas a mandar un string o un archivo
que luego hay que procesar, para mi es mejor crear un procedimiento
almacenado que lo recoja y lo distribuya por las tablas que crearlo con el
lenguaje de programación correspondiente.

Saludos

bueno, yo pregunté algo para escuchar opiniones, y las he escuchado de
las mas variadas, lo unico que se que me divertí un rato con el
revuelo armado :), realmente no era esa la intencion. Creo que
tendriamos que ir cerrando el hilo ya que veo que hay posturas muy
contrapuestas.

Sin animos de seguir haciendo mas ruido de esto, realice pruebas con
VFP y MySQL, medi el tiempo para una consulta sobre una tabla de
1000000 de registros, y con PA es mas rapido.

De ahi a que todo haya que hacerlo con PA, eso es algo que cada uno
tendrá que decidir como realizarlo, es cierto que con los PA lo que
permite que desarrolles algo en VFP y otro dia se te ocurre realizarlo
con PHP y lo unico que tienes que saber que parametros necesita el PA
para insertar, actualizar, borrar o recuperar datos y no necesitas
escribir nuevamente la sentencias, que haciendolo mediante SPT si
tendrias que escribirla de nuevo.

Asi que bueno, algo mas he aprendido y gracias por todos los
comentarios.

Saludos desde Misiones (La Hermosa) - Republica Argentina

El Fri, 25 Apr 2008 22:47:43 -0500, J. Enrique Ramos Menchaca escribió:

Ya me canse de leer un hilo tan largo y repetitivo. Aparte poco conclusivo.

Siento que te hayas cansado.

Creo que una de las ventajas de los procedimientos almacenados que han
olvidado mencionar, es que se pueden reutilizar en distintos lenguajes de
programación, a que me refiero con eso, a que no debo de escribir la misma
secuencia de comandos, en visual studio .net, java, visual foxpro, php,
etc

Es que creo que es bastante irrelevante para lo que estamos discutiendo de
verdad que es si hay que ocultarles todas las tablas a los usuarios para
que estos solo vean un conjunto de SP.


Saludos
Alfredo