mejorar update

Tolo!! yo uso la misma terminologia para los update de ese tipo!! no he
tenido problemas ni detectado baja en performance por ello

Con lo que mencionas de ser mas lejible!! creo q al usar una funcion UPDATE
completa es bastante lejible por mas q sean muchos campos.

Ojo esta es mi opinion Tolo!! quizas alguno aqui crea q hay alguna forma
mas practica de mayor rendimiento.

Un saludo

Accotto Maximiliano Damian
Fundicion San Cayetano S.A.
Buenos Aires Argentina

Gerente de Sistemas y Tecnologia
()

" Tolo" escribió en el mensaje
news:

hola, vereis tengo un update metido en un trigger bastante cañero, pero
resumiendo tengo algo como esto:

update T_lineasDocumento
set
Basei = Inserted.precio_unitario*inserted.unidades, --
PU*unidades
total = (Inserted.precio_unitario*inserted.unidades) +
f_impuesto(Inserted.precio_unitario*inserted.unidades) -- Basei +

Impuesto

de la Basei
from T_lineasDocumento inner join inserted on
inserted.id_linea=T_lineasDocumento .id_linea

Claro, aquí para hacer referencia cada vez a la Basei tengo que escribir

la

función, imaginaros estoen un caso real donde hay a parte de estos campos
los campos, Precio_unitario, Precio unitario neto, descuento unitario,

total

descuento, descuento, baseineto, baseibruto, total, importe impuesto, ...

claro, se me hacen las funciones interminables, más que por tema

rendimiento

(q también algo afectará supongo) me gustaria poder simplificarlo por tema
de legibilidad del código.

alguna idea.

gracias

PD: si ya se que puedo usar campos calculados, pero luego siempre q queira
una select debo estar volviendo a escribir la fórmula y gastando tiempo

de

cpu (creo yo inutilmente, pues hoy en día lo barato es el espacio en disco

y

lo caro la memoria y la cpu, aparte de caro limitado).

Gracias (2)

Hola,

sip, pero el problema viene cuando tengo q usar un campo en varios sitios,
por ejemplo un campo que me calcule el pmpc, entonces tengo que llamar a la
función pmpc cada vez q necesito usar ese valor ... uffff, demasiado pesado,
no?

no se, se me ocurre hacer algo del estilo

DECLARE @bLock int
DECLARE @cbMarq int

DECLARE c_Delete CURSOR LOCAL FOR SELECT cbMarq FROM deleted




EXECUTE CB_IsRecordLock 'F_COMPTET',@cbMarq,@bLock
OUTPUT

IF @bLock = 1

BEGIN

CLOSE c_Delete

DEALLOCATE c_Delete

Raiserror(80003,11,1) WITH SETERROR

Rollback Transaction

Return

END

FETCH NEXT FROM c_Delete INTO @cbMarq

END



o sea, leer cada registro, meter los valores en variables y calcular
registro por registro modificado ayudado por variables, como lo veis???

"Accotto Maximiliano Damian" escribió
en el mensaje news:

Tolo!! yo uso la misma terminologia para los update de ese tipo!! no he
tenido problemas ni detectado baja en performance por ello

Con lo que mencionas de ser mas lejible!! creo q al usar una funcion

UPDATE

completa es bastante lejible por mas q sean muchos campos.

Ojo esta es mi opinion Tolo!! quizas alguno aqui crea q hay alguna forma
mas practica de mayor rendimiento.

Un saludo

Accotto Maximiliano Damian
Fundicion San Cayetano S.A.
Buenos Aires Argentina

Gerente de Sistemas y Tecnologia
()

" Tolo" escribió en el mensaje
news:
> hola, vereis tengo un update metido en un trigger bastante cañero, pero
> resumiendo tengo algo como esto:
>
> update T_lineasDocumento
> set
> Basei = Inserted.precio_unitario*inserted.unidades, --
> PU*unidades
> total = (Inserted.precio_unitario*inserted.unidades) +
> f_impuesto(Inserted.precio_unitario*inserted.unidades) -- Basei +
Impuesto
> de la Basei
> from T_lineasDocumento inner join inserted on
> inserted.id_linea=T_lineasDocumento .id_linea
>
> Claro, aquí para hacer referencia cada vez a la Basei tengo que escribir
la
> función, imaginaros estoen un caso real donde hay a parte de estos

campos

> los campos, Precio_unitario, Precio unitario neto, descuento unitario,
total
> descuento, descuento, baseineto, baseibruto, total, importe impuesto,

...

>
> claro, se me hacen las funciones interminables, más que por tema
rendimiento
> (q también algo afectará supongo) me gustaria poder simplificarlo por

tema

> de legibilidad del código.
>
> alguna idea.
>
> gracias
>
> PD: si ya se que puedo usar campos calculados, pero luego siempre q

queira

> una select debo estar volviendo a escribir la fórmula y gastando tiempo
de
> cpu (creo yo inutilmente, pues hoy en día lo barato es el espacio en

disco

y
> lo caro la memoria y la cpu, aparte de caro limitado).
>
> Gracias (2)
>
>

disculpa pero lo veo mucho mas lento y pesado a la hora de leer!! (yo no
comparto el uso de cursores en SQL)

Un saludo

Accotto Maximiliano Damian
Fundicion San Cayetano S.A.
Buenos Aires Argentina

Gerente de Sistemas y Tecnologia
()

" Tolo" escribió en el mensaje
news:

Hola,

sip, pero el problema viene cuando tengo q usar un campo en varios sitios,
por ejemplo un campo que me calcule el pmpc, entonces tengo que llamar a

la

función pmpc cada vez q necesito usar ese valor ... uffff, demasiado

pesado,

no?

no se, se me ocurre hacer algo del estilo

DECLARE @bLock int
DECLARE @cbMarq int

DECLARE c_Delete CURSOR LOCAL FOR SELECT cbMarq FROM deleted




EXECUTE CB_IsRecordLock 'F_COMPTET',@cbMarq,@bLock
OUTPUT

IF @bLock = 1

BEGIN

CLOSE c_Delete

DEALLOCATE c_Delete

Raiserror(80003,11,1) WITH SETERROR

Rollback Transaction

Return

END

FETCH NEXT FROM c_Delete INTO @cbMarq

END



o sea, leer cada registro, meter los valores en variables y calcular
registro por registro modificado ayudado por variables, como lo veis???

"Accotto Maximiliano Damian" escribió
en el mensaje news:
> Tolo!! yo uso la misma terminologia para los update de ese tipo!! no he
> tenido problemas ni detectado baja en performance por ello
>
> Con lo que mencionas de ser mas lejible!! creo q al usar una funcion
UPDATE
> completa es bastante lejible por mas q sean muchos campos.
>
> Ojo esta es mi opinion Tolo!! quizas alguno aqui crea q hay alguna

forma

> mas practica de mayor rendimiento.
>
> Un saludo
>
> Accotto Maximiliano Damian
> Fundicion San Cayetano S.A.
> Buenos Aires Argentina
>
> Gerente de Sistemas y Tecnologia
> ()
>
> " Tolo" escribió en el mensaje
> news:
> > hola, vereis tengo un update metido en un trigger bastante cañero,

pero

> > resumiendo tengo algo como esto:
> >
> > update T_lineasDocumento
> > set
> > Basei = Inserted.precio_unitario*inserted.unidades, --
> > PU*unidades
> > total = (Inserted.precio_unitario*inserted.unidades) +
> > f_impuesto(Inserted.precio_unitario*inserted.unidades) -- Basei +
> Impuesto
> > de la Basei
> > from T_lineasDocumento inner join inserted on
> > inserted.id_linea=T_lineasDocumento .id_linea
> >
> > Claro, aquí para hacer referencia cada vez a la Basei tengo que

escribir

> la
> > función, imaginaros estoen un caso real donde hay a parte de estos
campos
> > los campos, Precio_unitario, Precio unitario neto, descuento unitario,
> total
> > descuento, descuento, baseineto, baseibruto, total, importe impuesto,
...
> >
> > claro, se me hacen las funciones interminables, más que por tema
> rendimiento
> > (q también algo afectará supongo) me gustaria poder simplificarlo por
tema
> > de legibilidad del código.
> >
> > alguna idea.
> >
> > gracias
> >
> > PD: si ya se que puedo usar campos calculados, pero luego siempre q
queira
> > una select debo estar volviendo a escribir la fórmula y gastando

tiempo

> de
> > cpu (creo yo inutilmente, pues hoy en día lo barato es el espacio en
disco
> y
> > lo caro la memoria y la cpu, aparte de caro limitado).
> >
> > Gracias (2)
> >
> >
>
>

Hola Tolo:
Gracias por la PosData :)
Con gusto te ayudo con el Trigger, pero veamos si es cierto que los
campos calculados son mas lentos que las columnas fisicas. Este codigo esta
hecho muy rapido y a lo Copy Paste:
/* Crea un BD de Pruebas */
CREATE DATABASE TESTDESEMPENO
USE TESTDESEMPENO
GO
/* Crea Dos Tablas, iguales a la de Order Details */
/* de Northwind una ccon 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.
Las actualizaciones de datos deben ser de 4 a 10 veces mas lentas. Es
muy facil decir esto es mas rapido o mas lento, lo dificil es probarlo. :)

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.


Tolo escribio:

hola, vereis tengo un update metido en un trigger bastante cañero,
pero resumiendo tengo algo como esto:

update T_lineasDocumento
set
Basei = Inserted.precio_unitario*inserted.unidades, --
PU*unidades
total = (Inserted.precio_unitario*inserted.unidades) +
f_impuesto(Inserted.precio_unitario*inserted.unidades) -- Basei +
Impuesto de la Basei
from T_lineasDocumento inner join inserted on
inserted.id_linea=T_lineasDocumento .id_linea

Claro, aquí para hacer referencia cada vez a la Basei tengo que
escribir la función, imaginaros estoen un caso real donde hay a parte
de estos campos los campos, Precio_unitario, Precio unitario neto,
descuento unitario, total descuento, descuento, baseineto,
baseibruto, total, importe impuesto, ...

claro, se me hacen las funciones interminables, más que por tema
rendimiento (q también algo afectará supongo) me gustaria poder
simplificarlo por tema de legibilidad del código.

alguna idea.

gracias

PD: si ya se que puedo usar campos calculados, pero luego siempre q
queira una select debo estar volviendo a escribir la fórmula y
gastando tiempo de cpu (creo yo inutilmente, pues hoy en día lo
barato es el espacio en disco y lo caro la memoria y la cpu, aparte
de caro limitado).

Gracias (2)

Hola,

ok, puedes tener razón, a mi lo que no me convence de eso es que en cada
nueva consulta, tendría q volver a definir esos campos calculados, q en mi
caso son bastantes y no precisamente basados en una suma o resta.

Lo que si que no entiendo es porqué dices desnormalizar, o voy muy
equivocado o no hay ninguna froma normal que diga nada de esto ...

gracias por tu comentario, lo estudiaré a ver.

"Javier Loria" escribió en el mensaje
news:%

Hola Tolo:
Gracias por la PosData :)
Con gusto te ayudo con el Trigger, pero veamos si es cierto que los
campos calculados son mas lentos que las columnas fisicas. Este codigo

esta

hecho muy rapido y a lo Copy Paste:
/* Crea un BD de Pruebas */
CREATE DATABASE TESTDESEMPENO
USE TESTDESEMPENO
GO
/* Crea Dos Tablas, iguales a la de Order Details */
/* de Northwind una ccon 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.
Las actualizaciones de datos deben ser de 4 a 10 veces mas lentas. Es
muy facil decir esto es mas rapido o mas lento, lo dificil es probarlo. :)

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.


Tolo escribio:
> hola, vereis tengo un update metido en un trigger bastante cañero,
> pero resumiendo tengo algo como esto:
>
> update T_lineasDocumento
> set
> Basei = Inserted.precio_unitario*inserted.unidades, --
> PU*unidades
> total = (Inserted.precio_unitario*inserted.unidades) +
> f_impuesto(Inserted.precio_unitario*inserted.unidades) -- Basei +
> Impuesto de la Basei
> from T_lineasDocumento inner join inserted on
> inserted.id_linea=T_lineasDocumento .id_linea
>
> Claro, aquí para hacer referencia cada vez a la Basei tengo que
> escribir la función, imaginaros estoen un caso real donde hay a parte
> de estos campos los campos, Precio_unitario, Precio unitario neto,
> descuento unitario, total descuento, descuento, baseineto,
> baseibruto, total, importe impuesto, ...
>
> claro, se me hacen las funciones interminables, más que por tema
> rendimiento (q también algo afectará supongo) me gustaria poder
> simplificarlo por tema de legibilidad del código.
>
> alguna idea.
>
> gracias
>
> PD: si ya se que puedo usar campos calculados, pero luego siempre q
> queira una select debo estar volviendo a escribir la fórmula y
> gastando tiempo de cpu (creo yo inutilmente, pues hoy en día lo
> barato es el espacio en disco y lo caro la memoria y la cpu, aparte
> de caro limitado).
>
> Gracias (2)