Store Procedure ¿ ?

Hola,

On 7 nov, 23:18, "Jose Antonio" wrote:

"Carlos M. Calvelo" escribió en el mensajenews:
On 5 nov, 23:27, "Jose Antonio" wrote:

> Todavía no me has contestado a mi pregunta, tan dificil es?
>No es ni difícil ni fácil. Simplemente no le veo sentido.
>Y ya es el tercer sinsentido por tu parte y yo sé cuando >parar.
>El cuarto sinsentido es que pareces pensar que yo tengo >la
>oblicación de responder (a sinsentidos o a lo que sea)

No hace falta que te pongas asi, solo queria saber que hacias tu en los sps,
ya veo que no los utilizas. Hay opiniones para todo.

Ya! Me doy cuenta ahora que no podías querer preguntar lo que
ponías literalmente. Tu pregunta era:

"Entonces me quieres decir que programas tu en los procedimientos
almacenados
si no es con instrucciones sql?"

Respuesta:
Programe lo que programe en un SP pues será preferiblemente con
instrucciones SQL y si no se puede, pues con otras construcciones.
Con condicionales, bucles, cursores, variables, expresiones,
llamadas a otros SP y funciones, con :-)

Ridículo total. Pero vamos... mi interpretación literal de la
pregunta no ha sido menos torpe que la pregunta.

Y yo no digo que no se utilicen (o que yo no los utilice), o que no
tengan aplicación. Eso ya lo he comentado.

De todas las maneras todos damos nuestras opiniones que son siempre
teoricas, no estaría de más que todos los que predicamos que es buena una
cosa u otra, lo certificasemos con alguna demostración realista y pública, y
me incluyo en ese grupo.

Creo que es difícil poner ejemplos porque las ventajas o
desventajas de un mecanismo u otro tendrán que compararse
en el contexto de un diseño y unos requerimientos para poder
considerar las consecuencias. Escalabilidad, eficiencia,
independencia o dependencia de las aplicaciones, división clara
entre lo que pertence al nivel lógico o a nivel físico, y un
largo etcétera.

Pero si tengo una estructura lógica de tablas/vistas, para asignar
nuevos valores a esas tablas tenemos insert, update y delete y
para consultar tenemos SQL, que con sus operadores básicos (select,
join, where, union, etc.) nos ofrece un lenguaje que es mucho mas
flexible y potente que el simple nombre de un procedimiento con
sus parámetros o cualquier biblioteca de procedimientos.
Para que eso tenga algún sentido (el hacerlo por medio de SP's)
no se debería dar acceso directo a las tablas que solo se deberían
acceder desde esos SP's.

Vamos... que esa forma de hacer las cosas es una barbaridad y
sin embargo precisamente lo que están 'vendiendo' algunos.
Ese esquema lógico es público a toda la organización (a todas las
aplicaciones, incluso aquellas de las que no se sabe que se van
a desarrollar en el futuro) y no debe esconderse detrás de una
interfaz mediocre como lo es una biblioteca de procedimientos.

Eso ya no es simplemente cuestión de 'opiniones'. No todas las
opiniones son igual de respetables. El que promueva lo que
describo aquí arriba, simplemente no tiene ni idea de lo que
es una base de datos relacional, ni sabe que es un SGBD,
ni tiene idea sobre gestión de datos y sistemas de información.

Todo eso no quiere decir que no se deben utilizar SP's. Solo
quiere decir que sus aplicaciones son otras. Bien utilizadas,
podrían considerarse Žpequeñas aplicacionesŽ que van con la base de
datos, o que proporcionan alguna funcionalidad a una o varias
aplicaciones por motivos de eficiencia y/o para compartir esa
funcionalidades con otras aplicaciones.
O sea que, para aquellas tareas que lógicamente no sería necesario
que estén en la base de datos, pero que en la práctica es bastante
conveniente centralizarlas (eficiencia, por ejemplo) y hasta
compartirlas.

Eso es hablando solo de SP's que forman parte de la interfaz con
las aplicaciones. Internamente se pueden también utilizar como
implentación de otros mecanismos. En este último sentido podemos
considerar que triggers y sp's son lo mismo y que pertencen al
nivel físico, como por ejemplo los índices. Pero no es esto último
de lo que se habla todo el rato.

Espero que el nivel de 'esmero' por mi parte sea ahora de su agrado.
Si no entiende de lo que hablo (aunque hago lo que puedo) no me
queda mas que remirle a usted al libro que ya he recomendado en
otra reacción en este hilo. Y eso lo hago desde el respeto y
tratando de evitar ser un 'tocapelotas' :-)

Saludos,
Carlos

Gracias por tu 'esmero', pero si ese es tu punto de vista, no se que hacemos
discutiendo desde hace un rato, ya que yo pienso y actuo practicamente
igual.

Creo que el café me ha puesto un poco nervioso, llegué a entederte que los
sps no debieran de existir, aunque no escribiste esa frase.

Conozco a gente que escribe 4 sps por tabla, uno para insert, otro para
update, otro para delete y otro para select, siempre insertan todas las
columnas hacen el update de todas o el select de todas independientemente de
las que vayan a utilizar despues. Siempre he considerado esto fuera de
cualquier logica y te puedo asegurar que hay mucha gente que lo hace.

Aprovechandome de tu experiencia, si que te quiero comentar uno de los casos
que sí utilizo un sp, por si estuviese equivocado y hay una manera distinta
que sea más aconsejable utilizar.

Hay veces que necesito duplicar información que esta en varias tablas, por
lo qur hago un sp pasandole los parametros de la clave origen, la clave
destino y la descripción del destino, todos los demas datos deben de
duplicarse, comienzo una transaccion, inserto en las tablas con la nueva
clave primaria el select de la clave origen y las columnas necesarias y
cuando lo he realizado en todas las tablas y no ha habido errores termino la
transaccion, sino la cancelo.

Se que puedo hacerlo con sql desde la propia aplicación, funciona igual,
pero he hecho pruebas y ejecutandolo varias veces seguidas (lo suelo hacer
mil veces) termina antes el sp que las instrucción directamente desde la
aplicación.

Ya se que esto es rizar el rizo, porque esta duplicación solo se hace de vez
en cuando.

Entiendes que es correcto de esta manera o desconozco algo que me daria más
rendimiento o más seguridad?


Un saludo y perdón por las molestias.

José Antonio
"Carlos M. Calvelo" escribió en el mensaje
news:
Hola,

On 7 nov, 23:18, "Jose Antonio" wrote:

"Carlos M. Calvelo" escribió en el
mensajenews:
On 5 nov, 23:27, "Jose Antonio" wrote:

> Todavía no me has contestado a mi pregunta, tan dificil es?
>No es ni difícil ni fácil. Simplemente no le veo sentido.
>Y ya es el tercer sinsentido por tu parte y yo sé cuando >parar.
>El cuarto sinsentido es que pareces pensar que yo tengo >la
>oblicación de responder (a sinsentidos o a lo que sea)

No hace falta que te pongas asi, solo queria saber que hacias tu en los
sps,
ya veo que no los utilizas. Hay opiniones para todo.

Ya! Me doy cuenta ahora que no podías querer preguntar lo que
ponías literalmente. Tu pregunta era:

"Entonces me quieres decir que programas tu en los procedimientos
almacenados
si no es con instrucciones sql?"

Respuesta:
Programe lo que programe en un SP pues será preferiblemente con
instrucciones SQL y si no se puede, pues con otras construcciones.
Con condicionales, bucles, cursores, variables, expresiones,
llamadas a otros SP y funciones, con :-)

Ridículo total. Pero vamos... mi interpretación literal de la
pregunta no ha sido menos torpe que la pregunta.

Y yo no digo que no se utilicen (o que yo no los utilice), o que no
tengan aplicación. Eso ya lo he comentado.

De todas las maneras todos damos nuestras opiniones que son siempre
teoricas, no estaría de más que todos los que predicamos que es buena una
cosa u otra, lo certificasemos con alguna demostración realista y pública,
y
me incluyo en ese grupo.

Creo que es difícil poner ejemplos porque las ventajas o
desventajas de un mecanismo u otro tendrán que compararse
en el contexto de un diseño y unos requerimientos para poder
considerar las consecuencias. Escalabilidad, eficiencia,
independencia o dependencia de las aplicaciones, división clara
entre lo que pertence al nivel lógico o a nivel físico, y un
largo etcétera.

Pero si tengo una estructura lógica de tablas/vistas, para asignar
nuevos valores a esas tablas tenemos insert, update y delete y
para consultar tenemos SQL, que con sus operadores básicos (select,
join, where, union, etc.) nos ofrece un lenguaje que es mucho mas
flexible y potente que el simple nombre de un procedimiento con
sus parámetros o cualquier biblioteca de procedimientos.
Para que eso tenga algún sentido (el hacerlo por medio de SP's)
no se debería dar acceso directo a las tablas que solo se deberían
acceder desde esos SP's.

Vamos... que esa forma de hacer las cosas es una barbaridad y
sin embargo precisamente lo que están 'vendiendo' algunos.
Ese esquema lógico es público a toda la organización (a todas las
aplicaciones, incluso aquellas de las que no se sabe que se van
a desarrollar en el futuro) y no debe esconderse detrás de una
interfaz mediocre como lo es una biblioteca de procedimientos.

Eso ya no es simplemente cuestión de 'opiniones'. No todas las
opiniones son igual de respetables. El que promueva lo que
describo aquí arriba, simplemente no tiene ni idea de lo que
es una base de datos relacional, ni sabe que es un SGBD,
ni tiene idea sobre gestión de datos y sistemas de información.

Todo eso no quiere decir que no se deben utilizar SP's. Solo
quiere decir que sus aplicaciones son otras. Bien utilizadas,
podrían considerarse ´pequeñas aplicaciones´ que van con la base de
datos, o que proporcionan alguna funcionalidad a una o varias
aplicaciones por motivos de eficiencia y/o para compartir esa
funcionalidades con otras aplicaciones.
O sea que, para aquellas tareas que lógicamente no sería necesario
que estén en la base de datos, pero que en la práctica es bastante
conveniente centralizarlas (eficiencia, por ejemplo) y hasta
compartirlas.

Eso es hablando solo de SP's que forman parte de la interfaz con
las aplicaciones. Internamente se pueden también utilizar como
implentación de otros mecanismos. En este último sentido podemos
considerar que triggers y sp's son lo mismo y que pertencen al
nivel físico, como por ejemplo los índices. Pero no es esto último
de lo que se habla todo el rato.

Espero que el nivel de 'esmero' por mi parte sea ahora de su agrado.
Si no entiende de lo que hablo (aunque hago lo que puedo) no me
queda mas que remirle a usted al libro que ya he recomendado en
otra reacción en este hilo. Y eso lo hago desde el respeto y
tratando de evitar ser un 'tocapelotas' :-)

Saludos,
Carlos

Déjalos, que la envidia es libre.


"Pedro" escribió en el mensaje
news:

El Thu, 6 Nov 2008 00:56:43 -0800 (PST), Juan Diego Bueno escribió:

yo seguiré con la mía. Yo no tengo ni tu
formación, ni la de Alfredo o Carlos, así que no me voy a meter en
charcos contigo :)

Maxi no tiene formación, lo que tiene es entrenamiento, y el
entrenamiento
sin formación es muy peligroso, y Maxi es el ejemplo perfecto de ello.

Yo pienso que poder estar equivocado en algo es una cosa pero decir que
una persona como Maxi no tiene formación pienso que es exagerado.

Despues ustedes dicen que los que ofenden son los otros.

Hola,

On 8 nov, 16:16, "Jose Antonio" wrote:

Gracias por tu 'esmero', pero si ese es tu punto de vista, no se que hacemos
discutiendo desde hace un rato, ya que yo pienso y actuo practicamente
igual.

Pues ya está. Es que este medio de comunicación se presta mucho
a la confusión.

Creo que el café me ha puesto un poco nervioso, llegué a entederte que los
sps no debieran de existir, aunque no escribiste esa frase.

Conozco a gente que escribe 4 sps por tabla, uno para insert, otro para
update, otro para delete y otro para select, siempre insertan todas las
columnas hacen el update de todas o el select de todas independientemente de
las que vayan a utilizar despues. Siempre he considerado esto fuera de
cualquier logica y te puedo asegurar que hay mucha gente que lo hace.

Pues eso! Eso es a lo que llamo yo una barbaridad.

Aprovechandome de tu experiencia, si que te quiero comentar uno de los casos
que sí utilizo un sp, por si estuviese equivocado y hay una manera distinta
que sea más aconsejable utilizar.

Hay veces que necesito duplicar información que esta en varias tablas, por
lo qur hago un sp pasandole los parametros de la clave origen, la clave
destino y la descripción del destino, todos los demas datos deben de
duplicarse, comienzo una transaccion, inserto en las tablas con la nueva
clave primaria el select de la clave origen y las columnas necesarias y
cuando lo he realizado en todas las tablas y no ha habido errores termino la
transaccion, sino la cancelo.

Se que puedo hacerlo con sql desde la propia aplicación, funciona igual,
pero he hecho pruebas y ejecutandolo varias veces seguidas (lo suelo hacer
mil veces) termina antes el sp que las instrucción directamente desde la
aplicación.

Ya se que esto es rizar el rizo, porque esta duplicación solo se hace de vez
en cuando.

Entiendes que es correcto de esta manera o desconozco algo que me daria más
rendimiento o más seguridad?

Pues no sé si entiendo bien. Pero me suena a ser un proceso que
no tiene que ver con integridad, o que para ello sea necesario
esconder la estructra, o que haciendolo así se salten las reglas
de integridad, etc. Vamos que suena a ser responsablidad de
una aplicación. En ese caso me parece un buen uso de los SP,
porque el servidor lo puede hacer mejor que la aplicación.
Digamos que es como un servico 'extra' que dá el SGBD a esa
aplicación. (no sé si me explico)

Saludos,
Carlos

Hola Jose Antonio,

El Sat, 8 Nov 2008 16:16:57 +0100, Jose Antonio escribió:

Conozco a gente que escribe 4 sps por tabla, uno para insert, otro para
update, otro para delete y otro para select, siempre insertan todas las
columnas hacen el update de todas o el select de todas independientemente de
las que vayan a utilizar despues. Siempre he considerado esto fuera de
cualquier logica y te puedo asegurar que hay mucha gente que lo hace.

Ya, ya, si eso es justo lo que intentamos criticar Carlos, yo y más gente.

Precisamente una de las cosas para las que se inventó el Modelo Relacional
es para evitarnos todo este trabajo.

Aprovechandome de tu experiencia, si que te quiero comentar uno de los casos
que sí utilizo un sp, por si estuviese equivocado y hay una manera distinta
que sea más aconsejable utilizar.

A ver, yo también me apunto a opinar :-)

Hay veces que necesito duplicar información que esta en varias tablas,

Con esto me llega para saber que está bien utilizado un SP.


Saludos
Alfredo