¿Programo bien?

On Wed, 31 Jan 2007 11:30:00 -0800, carlosmsr
wrote:

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.

Cierto si trabajás con bases pequeñas y de relaciones simples.

La mayoría lo hacemos.

Hay bases de
datos que debido a volumenes de información que almacenan y a la cantidad de
consultas simultáneas que deben responder exigen hasta el más mínimo ahorro
de tiempos.

Ya, por eso he puesto "suele". Y aun en esas bases de datos seguro que
hay consultas que se ejecutan muy de vez en cuando.

50 milisegundos en una consulta pueden significar errores por
timeout debido a los bloqueos que un query debe ejecutar en la base y que
crecen exponencialmente en función de la cantidad de concurrencias que se
deben soportar.

Pues en esos casos preparas las consultas y listo.

Pero durante la compilación de una consulta no se suelen producir
muchos bloqueos. Eso es más bien cuando se ejecutan.

Además los SGBD buenos ya no tienen bloqueos :-)

La tendencia actual son los sistemas de concurrencia optimista.

Por lo demás, no hay muchas otras correcciones particulares que hacer. Pero
sí suele ser un error común y muy general de los desarrolladores pensar que
hay "una manera mejor" a todas las demás y olvidarse de que no hay soluciones
que puedan ser evaluadas prescindiendo del contexto en el que se da el
problema.

Yo creo que el error común es todo lo contrario. Pensar que cualquier
cosa vale y que no hace falta analizar las cosas objetivamente.

Lo que está claro es que si que hay maneras mejores que otras en
cualquier contexto.


Saludos

Hola Ricardo,

On Wed, 31 Jan 2007 15:35:47 -0400, "Ricardo Passians"
wrote:

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.

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?

Todos los triggers son SP, pero no todos los SP son triggers. Trigger
es una abreviatura de Triggered Procedure, que a su vez es una
abreviatura de Triggered Stored Procedure.

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.

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. Por eso solo deben de usarse cuando no se pueda
hacer de otra manera, que es lo que quería decir desde el principio.

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, y
además el mejor plan puede variar con el tiempo así que conviene
recalcularlo de vez en cuando.

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.

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.

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.

Bueno, si estás hablando de triggers para acumular cantidades o balances (y
agilizar consultas), pues claro que con una vista indexada puedes evitarlos.
Pero, primero, los triggers no son sólo para ese de tipo cálculos
redundantes

Ya lo se.

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.

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.

Por sólo citar algo simple: actualizar un
estatus, controlar un límite de crédito, controles de auditoría,
actualización cruzada, etc. etc.
Una vista indexada básicamente te servirá para agilizar consultas de
valores acumulados. Su ámbito es muy limitado.

Eso ya es mucho. A nosotros algunas consultas nos pueden pasar de
tardar minutos a tardar décimas de segundo.

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.

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.

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.

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

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

en fin todo lo que envuelve T-SQL
que por si no sabías es también un lenguaje de programación.

Todos los SQL lo son.

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.

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.

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?

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

Si ese fuese el caso entonces sería un defecto grave de SQL Server y
no una ventaja de los SP.

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

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.

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.

http://blogs.msdn.com/sqlprogrammab...ation.aspx
http://blogs.msdn.com/sqlprogrammab...avior.aspx

No se puede mapear una tabla con una clase por que es absurdo, lo que

se hace es mapear una tabla con un objeto de tipo colección.

Objeto de tipo colección, pero de qué? de objeto de un tipo de clase que
mapea una tabla ?

No, de objetos que mapean a una fila.

No estarás diciendo lo mismo que dices que es absurdo?

Es que no es lo mismo, es muy distinto.

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.



Saludos
Alfredo

¿como que lo mismo que si usastablas e índices?.

eSTOy intentando seguir el hilo y no veo claro esta cuestión

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 y si es una aplicación
distribuida entiendo que tendré que cambiar todos los puestos de trabajo.
¿he entendido mal ?.

bye1

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

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.

Cierto si trabajás con bases pequeñas y de relaciones simples.

La mayoría lo hacemos.

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