¿Programo bien?

Estoy contigo1

On Thu, 1 Feb 2007 00:22:08 +0100, "Carmelo J. Morales Muñoz"
wrote:

Si uso llamadas a proc. almacenados, queda abstraido en la capa de datos,
pero si uso la llamada desde la aplicación, si hay un cambio de motor de
base de datos me obliga a cambiar el ejecutable

No tiene por que ser así. Si tienes un poco de cuidado puedes usar
sentencias SQL que funcionen con cualquier SGBD SQL. Además hay mucha
diferencia en como se implementan los SP en cada SGBD.

Saludos

On Thu, 1 Feb 2007 00:24:41 +0100, "Carmelo J. Morales Muñoz"
wrote:

Destrás de la capa de presentación ya solo está el usuario.

Hecha la capa de negocio, hacer un interface
para windows o web me supone poco esfuerzo...y por no hablar de la extrema
claridad del código.

Ya, y a mi hacer la capa de negocio dentro del SGBD me supone mucho
menos esfuerzo que a alguien que la programe en un lenguaje de bajo
nivel no orientado a bases de datos como C#.

Eso dependerá de la complejidad de las reglas de negocio porque puede
rendundar en baja optimización

Cuanta más complejidad más se gana utilizando un lenguaje de alto
nivel.

Saludos

On Thu, 1 Feb 2007 00:27:01 +0100, "Carmelo J. Morales Muñoz"
wrote:

áquí te doy la razón, pero por insignificante que sea una aplicación,
almenos por mi parte, la desarrollo pensando que va a ser el *no da mas* de
las aplicaciones y que puede que todo el munda quiera usarla, de ese modo en
el mejor de los casos irá y en el peor también.

Pues yo siempre pienso en cuanto me van a pagar y cuanto voy a tardar
en hacerla. Intento no gastar mucho tiempo en algo que nadie va a
notar.

Saludos

No usar SP's ???!!! Para mi estás absolutamente equivocado.

No digo que no se deban usar, digo que hay que usarlos lo menos que se
pueda.

Supongo que la mayor parte de la discrepancia viene de este
malentendido.

Dijiste en el mensaje anterior: "No, lo que conviene es no usar los SP"

No sé qué relación ves entre un SP y un trigger ya que son conceptos
totalmente distintos.

Un trigger no es más que un SP que se dispara automáticamente cuando
se cumple una condición. ¿Seguro que son conceptos totalmente
distintos?

De acuerdo. Yo interpreté que asociabas los SP's a la integridad.
Tecnicamente es cierto que los triggers son tipos especiales de SP pero como
aclaras luego, lo inverso no concuerda. Ahora bien, reconozco que yo di al
término SP, la acepción que normalmente le damos todos, diferenciada de
trigger, no la estrictamente técnica, ya que si nos fueramamos a lo
estrictamente técnico, con las cosas que dices en tu mensaje tendríamos para
pasarnos meses discutiendo.

Todos los triggers son SP, pero no todos los SP son triggers.

Ahora está más claro.

Si te refieres a la integridad declarativa,
fríamente hablando los SP's no tienen nada que ver. Los triggers, como
las
restricciones (check, relaciones...) sí son para mantener integridad.

Y para más cosas como para mantener datos agregados como stocks.

También, pero si en vez de calcularlos cada vez, los acumulas en una tabla o
vista indexada para fines de velocidad, esos datos calculados también
formarán parte de la "integridad" de tu BD. De no ser así, para qué los
mantienes calculados entonces si podrías hacer un SUM() cada vez?

La principal ventaja de usar SP's es la misma que la de usar
procedimientos
o métodos en cualquier ambiente de programación: encapsular lógica por su
complejidad o por su reusabilidad.

Si, pero son la peor y más primitiva forma de encapsular lógica de las
que dispone un SGBD.

A mi me luce que hablas de algo muy distinto que no comprendo qué es. Lo
digo porque esa afirmación está totalmente fuera de lugar para lo que
estamos discutiendo aquí.

Por eso solo deben de usarse cuando no se pueda
hacer de otra manera, que es lo que quería decir desde el principio.

Bueno, pues parece que hay miles de situaciones que no se pueden hacer "de
otra manera" en un SGBD normal. A la fecha actual.
Debe haber mucha gente equivocada con esto.

Otra ventaja: Los SP's (y también las funciones de usuario) guardan el
plan
de ejecución, eficientizando así el desempeño del servidor.

No es ninguna ventaja por que hay más formas de que se guarde

Vaya argumento.
Sip... hay mas formas... pero los SP's lo hacen de manera automática y
transparente al usuario o al administrador y de forma más persistente que
las demas. No es eso una ventaja? Las otras formas que dices son
automáticas también?

, y
además el mejor plan puede variar con el tiempo así que conviene
recalcularlo de vez en cuando.

A veces hasta me da risa como defiendes tus argumentos como en un esfuerzo
de "no perder nunca". Amigo, reconozca sus errores que nadie es infalible.

"De vez en cuando" no es lo mismo que tener "cada vez" que preparar
manualmente cuando se requiera postear una consulta, como sugieres en tus
mensajes. En todo caso, la administración normal de un SGBD implica por
ejemplo, regenerar las estadísticas periódicamente, reconstruir o agregar
índices recomendados, recompilar los sp's, etc. etc. pero... esas no son
labores por las que debamos preocuparnos frecuentemente ni los programadores
ni los DBA's.

Otra ventaja: La seguridad. Ej. Puedes desarrollar un sistema sin
conceder
a determinados usuarios (o a ninguno) acceso de modificación a las tablas
del sistema.

Otra falsa ventaja. Puedes hacer lo mismo sin usar SP.

Con la misma facilidad de mantenimiento ???!!! Menos trabajo y hasta algo
de mayor seguridad, no es una ventaja??????!!!! jaja.

Otra ventaja: Independizar la Base de Datos de las distintas aplicaciones.

Otra vez igual. Puedes crear diferentes vistas externas de la base de
datos y enseñar una vista distinta a cada aplicación.

por supuesto y los sp's, como los views, permisos, etc. contribuyen a
eso.

Cualquier aplicación para ejecutarlos solo debe conocer los parámetros de
llamada a los SP's y los conjuntos que devuelven o la accion final que
producen. Esto aunque (en un caso extremo) no conozcan siquiera la
estructura de las tablas.

Cualquier aplicación solo debe de conocer la estructura de la vista
externa que le corresponde y no tiene que saber nada sobre las
estructura física de los datos.

Vaya! por fin dices hasta aquí algo coherente en este mensaje.

y ,segundo, las vistas indexadas tampoco abarcan muchas
situaciones diversas que ayuden al control de integridad (puedes revisar
acerca de sus limitantes).

Si, están horriblemente limitadas en la versión actual de SQL Server,
pero muchas de esas limitaciones se pueden superar con un poco de
imaginación.

Me encantaria ver tus ejemplos especificos sobre esa tan "imaginativa"
afirmación. Por si no sabías, las vistas indexadas no surgieron en esta
versión. Tienen ya unos añitos de existencia.

Pero la utilidad principal de las vistas indexadas no es ayudar al
control de integridad sino evitar usar triggers (es decir SP) para
acumular cantidades.

Claro que sí. Pensé que sugerías otra cosa en tu mensaje anterior.

Depende de la aplicación que estés desarrollando. Sin duda que para
aplicaciones simples se aplica perfectamente lo que dices. De todos
modos,
con cada nueva versión de los SGBD el nivel de abstracción se incrementa
(ej. las consultas recursivas de SQL 2005) y el código que antes estaba en
SP's y triggers puede ahora ser parte declarativa del servidor.

Claro, de eso se trata. A SQL Server todavía le queda muchísimo por
mejorar, pero ese es el camino que hay que seguir: de procedimental a
declarativo.

De acuerdo.

Lo sospechaba. Ya veo que es evidente que has visto pocas consultas
complejas o quizás sólo has trabajado con aplicaciones pequeñas y/o de
pocos
usuarios. Hay determinadas consultas que requieren una lógica de
pre-procesamiento que definitivamente no puede establecerse en una simple
vista (view).

Cuanto mejor es el SGBD menos consultas de ese tipo hay.

Recomienda uno, hace tiempo que lo busco.

Son a veces necesarias tablas temporales, cursores, variables,
estructuras de control, iteraciones, etc.

A veces. Lo que hay que intentar es que sean las menos veces que sea
posible. Y para eso SQL Server tiene mucho que mejorar.

Claro que SQL debe mejorar. Y Oracle debe mejorar. Y MySQL debe mejorar.
Yo baso la discusión, como toda persona normal, en lo que hay actualmente;
no en lo que podría haber en un futuro.

Pero aun con todas las limitaciones de los SGBD actuales esto ocurre
mucho menos de lo que la mayoría de la gente piensa.

Insisto, depende del tipo de aplicaciones con que te enfrentes.

¿Podrías poner algún ejemplo de una consulta que necesite SP?

Si hablamos estrictamente de consultas de solo recuperacion de datos, que
"necesiten SP" son obviamente menos que las que los necesiten.

Pero algunos ejemplos podrían ser:

1-Especifico: Generar la tabla de amortización de un préstamo.
2-Especifico: Calcular los balances de las cuentas a un nivel de profundidad
específico (dada una relación reflexiva de la entidad "cuenta")
3-Mas genericos: a) Por limitaciones del SGBD: como subconsultas que
requieran varios group by y haya que usar una tabla temporal o variable tipo
table intermedia. Tambien los TOP tienen ciertas limitaciones en la
construcción de consultas y asi por estilo.
b) Por eficiencia para tablas voluminosas: Donde
sea mas eficiente (por plan de ejecución), traer algún dato puntual de una
tabla por su PK, y cargarlo a una variable para filtrar la(s) consulta(s)
posterior(es) y evitar seeks o scans innecesarios.
c) Reutilización del código de SP's: Cuando
requiera llamarse un SP ya existente como entrada de otras consultas
... d) Tambien por eficiencia: Combinar
actualización y consulta en un sólo "viaje" al servidor. Yo tengo por ej.
SP's de actualización que luego de la lógica que actualiza, me devuelven un
set con datos frutos de un select o de una llamada a otro SP o funcion.
Ahorra tiempo innecesario.
...
,,, y asi por el estilo.


Esos serian casos donde se podrian "necesitar". Pero en mi caso por las
multiples ventajas expuestas los uso tambien donde no solo se "necesiten"
sino tambien donde sean altamentes favorecedores de la encapsulación, de
claridad del código, de la seguridad y de la optimización del desempeño.

Aquí entra lo
de encapsular esa lógica en un SP del servidor para que éste se encargue
de
todo el proceso de forma transparente a la aplicación cliente.

Una vista es igual de transparente y tiene muchas ventajas sobre los
SP, por eso digo que los SP deben de ser un último recurso.

Ya es llover sobre mojado tener que repetirte lo mismo.

También ignoras el importante tema de la seguridad que resulta de dar
acceso
a un SP y no necesariamente a una tabla ni a sus campos en determinados
casos.

Me parece raro que ignores que no se necesita usar un SP para hacer
eso.


Yo puedo dar acceso a una vista y no necesariamente a la tabla que hay
por debajo y la vista puede enseñar los campos y los registros que yo
quiera.

En mi respuesta yo me basé en esta frase que escribiste: "¿Que diferencia
hay entre "amarrarse" a tablas que a SP?"
Mira yo uso vistas también, muchas y frecuentemente.
Nadie dice que no se pueda hacer con vistas. Solo cito (lo repito) como una
ventaja agregada de un SP la facilidad para la seguridad y tambien la mayor
fortaleza a la inyección de código. Mantener los permisos a una tabla (o a
una vista, ya que insistes) requiere mayor trabajo que a un SP que haga lo
mismo (ej. devolver una lista de clientes en mora), ya que los SPs en si
mismos no son objetos actualizables como las tablas y vistas. Sobre la
inyección de código normalmente los front-ends controlan mejor las llamadas
a SPs (suele haber instrucciones separadas para ellos) que a simples
consultas abiertas aunque estas sean "preparadas". Si estas no son ventajas
bueno allá tu que no lo quieras ver así en tu inútil esfuerzo por sustentar
tus ideas.
No sé si me entiendes. Por que la verdad ya lo estoy dudando :(

Hay más formas de precompilar como por ejemplo vistas y preparación de
consultas. Además el tiempo de compilación no suele ser muy
significativo. Si reduces el tiempo de una consulta en 50 milisegundos
nadie te lo va a agradecer.

Tienes razón... pero poca:). No sabes lo que es el plan de ejecución y
el
costo total una consulta en SQL Server?

¿Insinuas que en una consulta preparada no se reutiliza el plan? Si ese
fuese el caso entonces sería un defecto grave de SQL Server y
no una ventaja de los SP.

No estoy diciendo eso. Hasta sin preparar, si repites la misma consulta de
forma consecutiva, el servidor normalmente te guarda el plan en caché. Sólo
que con los SP's no hay que hacerlo manualmente. Lo hacen automáticamente en
la primera ejecuciojn y ademas persisten al cierre de la conexión de los
clientes, no se guardan solo en el cache por un tiempo. Eso es para mi una
grandísima ventaja sobre todo en consultas complejas, frecuentes y
concurrentes.

Pero te aclaro que la pregunta te la hice porque me dio la impresion que
cuando hablabamos de pre-compilacion no te referias al plan de ejecucion y
costo de la consulta. De hecho nunca mencionaste el termino propiamente. Por
eso pense que no conocias ese tema.

Además yo uso SQL Server lo menos que puedo.

Mira que se nota bastante pero es raro que estes migrando una aplicacion a
SQL Server como dijiste. Yo uso tambien Oracle, DB2, MySQL y Postgres por
si deseas hablar de otros SGBD's con los que te sientas mas comodo.

qué tal si fuesen varias
pre-consultas o consultas multi-set encapsuladas en un mismo SP?

Da igual. Preparas las consultas que sea y listo. Y si hay algún
problema la culpa la tiene el fabricante por no hacer las cosas bien
:)

Idem.

qué tal si
la cantidad de usuarios concurrentes se incrementa significativamente ?
Piensas que (siguiendo tu ejemplo) 50 milisegundos en cada petición al
servidor no sería significativo?

Pues las preparas y listo.

Insisto, no creo que hayas trabajado con
aplicaciones muy grandes ni con muchos usuarios,

Bueno, lo máximo unos 15.000 usuarios directos y en sistemas con
millones de lineas y docenas de aplicaciones. Pero no usaba SQL
Server. Para un sistema grande si puedo elegir me quedo con Oracle o
DB2.

La verdad que no parece. O al menos no fuiste el encargado de implementar
esas aplicaciones.

ya que estas cosas empiezan
a preocuparnos cuando nos topamos con esos casos.
Pero.. no te culpo, yo también ignoraba esas cosas cuando trabajaba sólo
con
pymes. Si no es tu caso, me disculpas pero debes revisar esa idea errónea
que tienes sobre los SP's y la precompilación de los planes de ejecución.

Por lo que he leido, con SQL Server las consultas parametrizadas y
preparadas reusan los planes de ejecución (y con otros SGBD desde
luego que si). Si no es así es MS el que debe de revisar SQL Server y
no yo mis ideas.

Malentendiste lo que dije pero esta bien. Allá tú. En vez de un SP's
prefiere mejor preparar cada consulta antes de postearlas al servidor. Es
tu problema fruto de tu ignorancia en el tema. Y eso que no hemos
profundizado con lo de la inyección de código en las consultas abiertas.
Pero en fin, ya me imagino los argumentos que inventarías para rebatir esto
también.

Jeje sin duda que esta vez respondiste lo que te dio la gana. Te
recomiendo que profundices un poco más sobre los Store Procedures ya que
tus
argumentaciones me parecen exageradamente pobres al respecto.

Pues la mayoría de las tuyas las he tumbado con 2 o 3 lineas.

No has tumbado absolutamente nada de lo que he dicho.

Si quieres podemos seguir discutiendo sobre las ventajas de los SP's pero
reconozco que será dificil pues tu único propósito es "tumbar" mis
respuestas diciendo en la mayoria de las veces, cosas teóricas sin ningún
fundamento, sin dar ejemplos claros y para colmo, como tú mismo admites
mencionando que estas migrando una aplicacion a SQL server, siendo un SGBD
que "no usas mucho".
No digo que no conozcas mucho sobre otros temas pues se nota que has leído,
pero sobre el tema particular de las ventajas de los SP's debes documentarte
mejor ya que puedes mal informar a otros colegas del foro que podrían seguir
tus mensajes.

Suerte con tus migraciones y tus preparaciones de queries.