Consejo

Bueno mal no esta pero eso depende de como? o sea vos en una factura tenes
lineas verdad y el total de la factura es la suma de los subtotales de las
lineas cierto?

Entonces cada vez que necesitas calcular el total estas haciendo una
consulta que suma los subtotales, esto se puede poner lento.

Aca tenes 2 opciones piolas

1) En la cabecera de la factura poner un campo Total y que se actualice via
trigger, entonces cuando necesitas saber el total de la factura solo debes
traer ese campo sin hacer JOIN ni SUM ni nada.

2) Te armas una vista Idexada donde resuelva esto, y cada vez que buscas el
Monto lo haces por esta vista.

La vista al ser indexada le podes poner indices por lo cual la performance
crece.

Bye


Salu2
Maxi
Buenos Aires Argentina
Desarrollador Microsoft 3 Estrellas .NET
[Maxi_accotto[arroba]speedy[punto]com[punto]ar
MSN:


"Jorge Eldis" escribió en el mensaje
news:

Buenas a Todos

El problema es el siguiente:

Tengo una aplicacion en SQL2000, y uno de sus modulos es el de

facturación,

en el cual guardo, [PRECIO UNITARIO], [IMPUESTO], [INTERES], pero el
total lo calculo en tiempo de corrida o "On Fly" como le llaman.

1- Algunos analistas me dicen que porque mejor no guardo el total de todo

a

la hora de facturar asi no tengo que calcular cada vez que abra una

factura.

2- Yo por mi parte planteo que no veo porque almacenar un resulatado el

cual

yo puedo calcular.

Pregunto porque no veo mal el consejo que me dan los analistas pero no veo
gran impacto en la manera que yo lo hago.

Que opinan ustedes?


Saludos y muchas gracias.

Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.593 / Virus Database: 376 - Release Date: 22/02/2004

Los puntos a considerar son:
1) Guardar calculos en una tabla va contra las reglas de normalización ya
que se trata de data derivada
2) Guardar el calculo consume espacio en disco
3) Si el calculo esta en la tabla se gana el performance involucrado en
realizar dicho calculo
4) Los programadores no tienen que hacer el calculo en sus aplicaciones

Guardar la data calculada normalmente es un problema ya que hay que
mantenerla actualizada, una mejor alternativa es agregar una columna
calculada en tu tabla, de manera que los programadores no necesitan
especificar el calculo. De esta manera solo se guarda la expresion no la
data. Si quieres que tambien se guarde la data puedes "Materializar" la
columna, para ello agregas un indice basado en dicha columna.

Saludos,

Anibal Marcano
Visualven Sistemas C.A.

"Jorge Eldis" wrote in message
news:

Buenas a Todos

El problema es el siguiente:

Tengo una aplicacion en SQL2000, y uno de sus modulos es el de

facturación,

en el cual guardo, [PRECIO UNITARIO], [IMPUESTO], [INTERES], pero el
total lo calculo en tiempo de corrida o "On Fly" como le llaman.

1- Algunos analistas me dicen que porque mejor no guardo el total de todo

a

la hora de facturar asi no tengo que calcular cada vez que abra una

factura.

2- Yo por mi parte planteo que no veo porque almacenar un resulatado el

cual

yo puedo calcular.

Pregunto porque no veo mal el consejo que me dan los analistas pero no veo
gran impacto en la manera que yo lo hago.

Que opinan ustedes?


Saludos y muchas gracias.

Hola Jorge:
Mi consejo: No cambies la tabla, cambia de "analistas".
Te copio un codigo de "Pruebas" que envie hace algunos meses a este
foro, y lo que hace es crear dos tablas una con un valor calculado "on Fly"
usando campos calculados, y el otro lo graba efectivamente en el disco en el
momento de insertar la fila:
/* Crea un BD de Pruebas */
CREATE DATABASE TESTDESEMPENO
USE TESTDESEMPENO
GO
/* Crea Dos Tablas, iguales a la de Order Details */
/* de Northwind una con campos Calculados y*/
/* otra con Columnas */
CREATE TABLE DetalleOrdenes (
OrderID int NOT NULL ,
ProductID int NOT NULL ,
UnitPrice money NOT NULL CONSTRAINT DF_Order_Details_UnitPrice
DEFAULT (0), Quantity smallint NOT NULL CONSTRAINT
DF_Order_Details_Quantity DEFAULT (1),
Discount real NOT NULL CONSTRAINT DF_Order_Details_Discount DEFAULT
(0), CONSTRAINT PK_Order_Details PRIMARY KEY CLUSTERED
(
OrderID,
ProductID
),
TotalBruto AS UnitPrice*Quantity,
TotalDescuentado AS UnitPrice*Quantity*(Discount),
TotalNeto AS UnitPrice*Quantity*(1-Discount),
CONSTRAINT CK_Discount CHECK (Discount >= 0 and Discount <= 1),
CONSTRAINT CK_Quantity CHECK (Quantity > 0),
CONSTRAINT CK_UnitPrice CHECK (UnitPrice >= 0)
)
GO

CREATE TABLE DetalleOrdenes2 (
OrderID int NOT NULL ,
ProductID int NOT NULL ,
UnitPrice money NOT NULL CONSTRAINT DF_Order_Details_UnitPrice2
DEFAULT (0),
Quantity smallint NOT NULL CONSTRAINT DF_Order_Details_Quantity2
DEFAULT (1),
Discount real NOT NULL CONSTRAINT DF_Order_Details_Discount2
DEFAULT (0), CONSTRAINT PK_Order_Details2 PRIMARY KEY CLUSTERED
(
OrderID,
ProductID
),
TotalBruto money NOT NULL,
TotalDescuentado money NOT NULL,
TotalNeto money NOT NULL,
CONSTRAINT CK_Discount2 CHECK (Discount >= 0 and Discount <= 1),
CONSTRAINT CK_Quantity2 CHECK (Quantity > 0),
CONSTRAINT CK_UnitPrice2 CHECK (UnitPrice >= 0)
)
GO

/* Insertemos unos 20,000 filas en ambas Tablas*/
INSERT DetalleOrdenes
SELECT OrderID + Numero*11500, ProductID, UnitPrice, Quantity,
Discount FROM Northwind.dbo.[Order Details]
CROSS JOIN
(SELECT 0 AS Numero UNION ALL
SELECT 1 UNION ALL
SELECT 2 UNION ALL
SELECT 3 UNION ALL
SELECT 4 UNION ALL
SELECT 5 UNION ALL
SELECT 6 UNION ALL
SELECT 7 UNION ALL
SELECT 8 UNION ALL
SELECT 9 UNION ALL
SELECT 10 ) AS N


INSERT DetalleOrdenes2
SELECT OrderID + Numero*11500, ProductID, UnitPrice, Quantity,
Discount, UnitPrice*Quantity, UnitPrice*Quantity*(Discount),
UnitPrice*Quantity*(1-Discount)
FROM Northwind.dbo.[Order Details]
CROSS JOIN
(SELECT 0 AS Numero UNION ALL
SELECT 1 UNION ALL
SELECT 2 UNION ALL
SELECT 3 UNION ALL
SELECT 4 UNION ALL
SELECT 5 UNION ALL
SELECT 6 UNION ALL
SELECT 7 UNION ALL
SELECT 8 UNION ALL
SELECT 9 UNION ALL
SELECT 10 ) AS N

/* Limpia los Buffers del Cache */
DBCC DROPCLEANBUFFERS

/************************************/
/************** Pruebas **************/
/************************************/
/* Primera Prueba */
SELECT ProductID,TotalBruto, TotalDescuentado, TotalNeto
FROM DetalleOrdenes
WHERE ProductID9

SELECT ProductID,TotalBruto, TotalDescuentado, TotalNeto
FROM DetalleOrdenes2
WHERE ProductID9

/* Segunda Prueba */
SELECT SUM(TotalBruto), SUM(TotalDescuentado), SUM(TotalNeto)
FROM DetalleOrdenes

SELECT SUM(TotalBruto), SUM(TotalDescuentado), SUM(TotalNeto)
FROM DetalleOrdenes2

/* Tercer Prueba */
SELECT ProductID,TotalBruto, TotalDescuentado, TotalNeto
FROM DetalleOrdenes2
WHERE OrderID337

SELECT ProductID,TotalBruto, TotalDescuentado, TotalNeto
FROM DetalleOrdenes
WHERE OrderID337
/* Fin de Codigo */
Revisas los planes de Ejecucion de las consultas veras que las dos
primeras son un 50% mas lentas en el segundo caso que en el primero.
O sea es bastante mas rapido NORMALIZAR que DESNORMALIZAR.
La ultima tiene el mismo desempeno.
Mientras los discos sean mas lentos que el procesador, la normalizacion
produce mejor desempeno, con MUY POCAS excepciones).

Saludos,


Javier Loria
Costa Rica
Se aprecia la inclusion de DDL (CREATE, INSERTS, etc.)
que pueda ser copiado y pegado al Query Analizer.
La version de SQL y Service Pack tambien ayuda.
Jorge Eldis escribio:

Buenas a Todos

El problema es el siguiente:

Tengo una aplicacion en SQL2000, y uno de sus modulos es el de
facturación, en el cual guardo, [PRECIO UNITARIO], [IMPUESTO],
[INTERES], pero el total lo calculo en tiempo de corrida o "On
Fly" como le llaman.

1- Algunos analistas me dicen que porque mejor no guardo el total de
todo a la hora de facturar asi no tengo que calcular cada vez que
abra una factura.

2- Yo por mi parte planteo que no veo porque almacenar un resulatado
el cual yo puedo calcular.

Pregunto porque no veo mal el consejo que me dan los analistas pero
no veo gran impacto en la manera que yo lo hago.

Que opinan ustedes?


Saludos y muchas gracias.