Select con campos calculados

Hola,

Lo que sugiero por la experienciea que llevo en manejo de bases de datos
es que no dejen que todo se procese o sobrecargue en una sentencia SQL,
ya que puede afectar el performance. Es mejor aplicar la logica del
negocio en procesos independientes que sean de facil mantenimiento ya que
el dia de mañana hay que pensar que puede cambiar las reglas de juego o lo
que se quiere mostrar y es más la carga para acomodar o desbaratar porque
esta afectando el rendimiento del servidor.

claro, las reglas de negocio deben poder simples de manejar y de mantener.
Primero hay que definir que es para vos una regla de negocios porque en el
ambito informatico hay una disparidad de ideas terribles y muchas veces se
confunde regla de negocio con integridad o parte de un proceso por ej (Si
hago una factura debo descontar del inventario).

Luego, te comento: Hoy dia con SQL2005 podes poner tu regla de negocios
completas en tu servidor, de hecho la inclusion de CLR esta para poder hacer
lo que antes no se podia con el simple TSQL y poder escalar distinto, ni
hablar de la inclusion de WebService y el Service Broker en el motor, como
dijo un representante de MS en el Ready05, SQL ya no es una base de datos
sino es todo un ambiente completo donde la idea es que se pueda hacer toda
una aplicacion (sin la capa de UI claro)

1. Sucede que SQL Server en la version 2000 no tiene un buen manejo con
los cursores en su rendimiento pero en la 2005 mejoraron y considero que
estos cursores tienen un comportamiento casi similar a un recordset de
ado, osea que mira el alcance que puedes sacar de ahi.

Esto no es tan asi, no hay que pensar en cursores por mas que hayan mejorado
en sql2005, pensa en conjunto de datos y no en recorrerlos y decime cuando
necesitas recorrerlos en una aplicacion comercial (no funciones de DBA) y lo
vemos.
Y te digo mas, los cursorrs no tienen ni comparacion con un recordset, hace
la prueba, pone un cursor y compara su rendimiento con un recordset, es mas
en sql2005 si usas CLR y haces un Datareader es mucho pero mucho mas rapido
que usar los cursores del propio motor.

2. Estoy de acuerdo en que en lo posible no se utilicen las tablas
temporales pero esta bondad que tiene SQL Server con las tablas # hasta
cierto punto pueden ayudar en los procesos que se pueden llegar a tener.

Antes de usar una tabla temporal hay que estudiarlo 100 veces, hay mucha
facilitismo en los desarrolladores y se tientan a usarlas sin pensar
alternativas, sin duda que si estan hay que usarlas pero bien, yo si las
puedo evitar las evito siempre

3. Considero que una base de datos no es solo un reporsitorio de datos y

objetos, pero en lo posible la logica del negocio debe tomarse en la
aplicacion. Claro uno puede crear procedimientos y function que ayuden en
la extraccion de los datos y ciertas operaciones las dejemos para que se
corran en el servidor. pero debemos contar con que la parte cliente
digiera la informacion como la necesita y no afecte el servicio del
servidos en otros procesos. En la version 2005 de SQL Server se cuenta
hasta con procedimientos que se pueden guardar en el lenguaje que uno
trabaje con .Net y esto algo que se debe saer explotar.

Bueno esto depende de que necesites y que quieres hacer con la logica de
negocios veamos un caso.

Logica de negocios en SP dentro de SQL:

Contras:

1) no me permite escalar a otro motor de forma simple
2) Si usas TSQL en la version 2000 la cosa se puede complicar mucho, si usas
CLR la cosa ya cambia mucho

Pros:

1) disminuyen las llamadas hacia el servidor, en ambientes donde el caño de
red es una limitacion esto puede ser un factor mas que importante
2) Permite la reutilizacion en cualquier aplicacion
3) Mejora el mantenimiento, si cambio un SP ya no debo hacer Deploy y ademas
si por ej cambio un campo en una BDD puedo saber quienes lo estan viendo

Entonces, eso de que la logica debe ir afuera es un texto que esta de moda,
no en todos los casos debe ir a fuera, creo que no hay que tomar modas sino
analizar bien las cosas y ver cuales son sus pros y contras. Ahora mismo
estoy armando un sistema en VS2005 + SQL2005 donde toda pero toda la logica
estara en SQL2005 con CLR lo que se pueda.

Espero que no tomes a mal mis palabras, no son nada contra ti, sino que
trato de exponer mis ideas y tratar de sacar modas del medio, analicen bien
antes las cosas, no hagan 20 capas si luego siempre usan el mismo motor, no
piensen que los objetos son la solucion a todos los problemas y que uno de
sus fuertes es la reutilizacion si luego en la practica cada vez que haces
un ABM lo debes reconstruir, no crean que los patrones son la unica realidad
y que sin ellos no se puede programar (GOF fue hecho hace 10 años mas o
menos y a mi gusto y como dice un amigo pensados para Hacer procedadores de
texto)

Si queres analizar un poco mas el tema te invito que busques un poco sobre
SODA ;-)

Un abrazo y feliz Año


Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Wilson R. Rico Camargo" escribió en el
mensaje news:%

Maxi:

Lo que sugiero por la experienciea que llevo en manejo de bases de datos
es que no dejen que todo se procese o sobrecargue en una sentencia SQL,
ya que puede afectar el performance. Es mejor aplicar la logica del
negocio en procesos independientes que sean de facil mantenimiento ya que
el dia de mañana hay que pensar que puede cambiar las reglas de juego o lo
que se quiere mostrar y es más la carga para acomodar o desbaratar porque
esta afectando el rendimiento del servidor.

Uno puede generar estore procedure que con base en un select que traiga la
informacion necesaria se continue con todas las reglas de negocio que
deben tener. y en cuanto a tus puntos:

1. Sucede que SQL Server en la version 2000 no tiene un buen manejo con
los cursores en su rendimiento pero en la 2005 mejoraron y considero que
estos cursores tienen un comportamiento casi similar a un recordset de
ado, osea que mira el alcance que puedes sacar de ahi.
2. Estoy de acuerdo en que en lo posible no se utilicen las tablas
temporales pero esta bondad que tiene SQL Server con las tablas # hasta
cierto punto pueden ayudar en los procesos que se pueden llegar a tener.
3. Considero que una base de datos no es solo un reporsitorio de datos y
objetos, pero en lo posible la logica del negocio debe tomarse en la
aplicacion. Claro uno puede crear procedimientos y function que ayuden en
la extraccion de los datos y ciertas operaciones las dejemos para que se
corran en el servidor. pero debemos contar con que la parte cliente
digiera la informacion como la necesita y no afecte el servicio del
servidos en otros procesos. En la version 2005 de SQL Server se cuenta
hasta con procedimientos que se pueden guardar en el lenguaje que uno
trabaje con .Net y esto algo que se debe saer explotar.

Las aplicaciones que yo trabajo almaceno la parametrizacion y las reglas
del negocio como expresion que despues se evaluan asi exploto SQL Server y
Exploto .Net.

Cordialmente,


Wilson R. Rico Camargo
BBVA Seguros
Bogotá - Colombia

(Oficina (571) 2191100 Ext. 1140
Móvil 300-2076572: Mensajes instantáneos
Visite www.bbvaseguros.com.co


"Maxi" escribió en el mensaje
news:uiP5$

Hola, perdon no, pero no coincido contigo: es cierto que los campos
calculados ayudan y mucho pero no siempre es bueno tenerlos, hay veces
que para una sola query necesito un calculo y no voy a tener un campo
calculado para eso.
Muchos menos coincido con tu segunda parte no:

calculos sean minimizados y crear procedimientos que evaluen los valores
ya sea recorreindo cursores, variables temporales, vistas, tablas
temporales o que sean evaluadas en el back (aplicacion).

Todo esto es una enorme mala practica de programacion:

1) No hay que usar cursores a menos para herramientas de DBA
2) Hay que minimizar las tablas temporales lo maximo posible
3) eso de que deba todo ser evaluado en la aplicacion tampoco es tan asi,
podrias tener lo mas bien tu BL dentro de SQL2005 en un Assembly y que
este se dedique a las evaluaciones



Salu2
Maxi [MVP SQL SERVER]
www.sqlgurus.org


"Wilson R. Rico Camargo" escribió en el
mensaje news:

Lo que sucede es que debes procurar que los calculos no se armen o se
resuelvan en el mismo Select para que te llegan más depurados porque
estas arriegando performance de la base de datos. debes establecer que
estos calculos sean minimizados y crear procedimientos que evaluen los
valores ya sea recorreindo cursores, variables temporales, vistas,
tablas temporales o que sean evaluadas en el back (aplicacion).
Cordialmente,


Wilson R. Rico Camargo
BBVA Seguros
Bogotá - Colombia

(Oficina (571) 2191100 Ext. 1140
Móvil 300-2076572: Mensajes instantáneos
Visite www.bbvaseguros.com.co


"Fabián" escribió en el mensaje
news:

Hola listeros, tengo una duda respecto a campos calculados en un
select.
En resumen necesito mostrar las cantidades de prestaciones menos las
cantidades de prestaciones que cumplan algunas condiciones para ello y
a modo
de ejemplo pongo esta sentencia.
Select año,mes,medicos,sum(cantidad) ,calculado from tabla t inner
join
(select medicos,sum(cantidad) as Calculado from tabla group by
año,mes,medicos,afiliado
having sum(cantidad)>2)
group by año,mes,medicos )as c
on
t.medicos=c.medicos
Otro criterio es que el grupo familiar haya tenido mas de 4 consultas
Para ello selecciono de esta forma.
select medicos,sum(cantidad) as Calculado1 from tabla group by
año,mes,medicos,substring(afiliado,1,9)
having sum(cantidad)>4)

El tema es que aparte tengo otros criteros que tener en cuenta los
cuales me
interesan ponerlos como columnas del primer select para poder restar la
cantidad original de las calculadas de los subqueries.
Esto es factible? Alguna sugerencia.

Saludos
Fabián