Sugerencias para Query

Hola Jesus:
Excelente exposicion, ayuda muchisimo a aclarar el tema.
El porcentaje de 3.8% no me parece demasiado loco, en un mundo .NET de
DataSets desconectados de aplicaciones que se dejan en cache una buena parte
de la BD durante una importante candidad de tiempo creo que los porcentajes
debes ser superiores al indicado.
En todo caso. Revisemos los supuestos.
(5) Tvd = 1,25 * Tv
(6) Tnv = 20* Tv
Que implica que una Validacion que se hace 2 veces? (Supuesto 5). En mi
opinion muy poco trabajo, ya que en el servidor es muy caro traer datos del
DD y muy barato los ciclos de comprobacion. Hacer 2 veces un CHECK es
trivial, hacer un SELECT a una Tabla para luego hacer una comprobacion de
Llave Foranea de la misma fila, genera poca carga proporcional a la
escritura de la BD y del Log, particulamente del Log que es sincronico.
Por otra parte cual es el ahorro de una transaccion que no se realiza.
Enorme !!!. En principio evitamos grabar en el Log (Los discos duros son 500
veces mas lentos que la memoria), evitamos el bloqueo (los otros ciclos
puedes seguir trabajando y no se congelan esperando el resultado final). Si
cambiamos los porcentajes para reflejar esta realidad :
(5) Tvd = 1,05 * Tv
(6) Tnv = 50* Tv
Los resultados de 10 y siguientes serian:
==(10) Tv * (1- Pnv) + 50*Tv * Pnv > 1,05 * Tv * ( 1 - Pnv ) + 0,5*Tv*Pnv
Tv - Pnv*Tv + 50*Tv * Pnv > 1,05 * Tv - 1,05*Tv*Pnv + 0,5*Tv*Pnv
Tv + 49*Tv * Pnv > 1,05 * Tv - 1,55*Tv*Pnv
1,55*Tv*Pnv + 49*Tv * Pnv > 1,05*Tv - Tv
50.55*Tv * Pnv > 0,05*Tv
pnv > 0.0098
== O sea poco menos de un 1%.
Mis pruebas practicas no son tan concluyentes, tengos casos de mejoras
usando de hasta el 50% en situaciones donde el servidor esta medianamente
ocupado o superior (por el ahorro en los bloqueos), y tengo casos de una
desmejora del 30% cuando el servidor no esta muy ocupado. Parece que la
programacion defensiva solo es mas rapida bajo situaciones de stress, cuando
hay abundancia de recursos (principalmente IO/Memoria) es mas lenta (hasta
un 30%).
En todo caso tu exposicion ayuda mucho a aclarar el punto y me permite
hacer un mejor marco teorico. Voy a seguir explorando el tema.
Saludos y muchas gracias,


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..
"SqlRanger [MVP .NET]" wrote in message
news:eWdNn3$
Javier,

Hagamos unas pocas cuentas para tener una idea más concreta de la cuestión.

Tenemos que sin usar el patrón "programación a la defensiva"

(1) Tm = Tv * Pv + Tnv * Pnv

Donde:

Tm: es el tiempo medio de una transacción sin programación a la defensiva
Tv: tiempo medio de una transacción con datos válidos sin programación a la
defensiva
Pv: porcentaje (en tanto por uno) de transacciones con datos válidos
Tnv: tiempo medio de una transacción con datos no válidos sin programación a
la defensiva
Pnv: porcentaje (en tanto por uno) de transacciones con datos no válidos

Y usando el patrón "programación a la defensiva":

(2) Tmd = Tvd * Pv + Tnvd * Pnv

Donde:

Tmd: es el tiempo medio de una transacción con programación a la defensiva
Tvd: tiempo medio de una transacción con datos válidos con programación a la
defensiva
Pv: porcentaje (en tanto por uno) de transacciones con datos válidos
Tnvd: tiempo medio de una transacción con datos no válidos con programación
a la defensiva
Pnv: porcentaje (en tanto por uno) de transacciones con datos no válidos

Para que la programación a la defensiva sea más eficiente tendrá que
culplirse que:

(3) Tm > Tmd

o lo que es lo mismo:

(4) Tv * Pv + Tnv * Pnv > Tvd * Pv + Tnvd * Pnv

Hagamos ahora algunas suposiciones:

Debido a que con la programación a la defensiva en una transacción con datos
válidos las restricciones de comprueban dos veces, el tiempo será mayor,
supongamos que es por ejemplo un 25% mayor . Es decir:

(5) Tvd = 1,25 * Tv

Debido a que sin programación a la defensiva hay que hacer un Rollback
cuando los datos no son válidos, el tiempo de una transacción con datos no
válidos es muy superior a de una con los datos válidos, supongamos que es
por ejemplo 20 veces superior. Es decir:

(6) Tnv = 20 * Tv

Debido a que con programación a la defensiva en una transacción con datos no
válidos no se hace ninguna modificación, el tiempo es incluso menor que el
de una transacción con datos válidos sin programación a la defensiva,
pongamos que es la mitad. Es decir:

(7) Tnvd = 0,5 * Tv

Como además se cumple:

(8) Pv + Pnv = 1

O lo que es lo mismo:

(9) Pv = 1 - Pnv

Sustituyendo (9), (7), (6) y (5) en (4) tenemos:

(10) Tv * ( 1- Pnv ) + 20 * Tv * Pnv > 1,25 * Tv * ( 1 - Pnv ) + 0,5 * Tv *
Pnv

Operando:

(11) 1 + 19 * Pnv > 1,25 - 0,75 * Pnv <=> 19,75 * Pnv > 0,75 <=> Pnv >
0,75/19,75

Con lo que al final nos queda:

(12) Pnv > 3,8%

Es decir, que con las suposiciones que hemos hecho anteriormente, para que
usar este patrón sea más eficiente que no usarlo, el porcentaje de
transacciones con datos no válidos tendría que ser superior al 3.8 %, lo que
a mi jucio es bastante improbable.

Desde luego, estas suposiciones son sólo eso, suposiciones, aunque creo que
estos números no deben de andar demasiado desencaminados. Habría que motar
un laboratorio o usar sistemas en producción y monitorizar para ver cuales
son en realidad estos números.

Saludos:

Jesús López
MVP .net