Independencia de los datos.

Hola Julio, tal y como comentaba leonardo la única forma de garantizar el
orden en un select es colocarle un order by.
De hecho aunque con loop join ahora te los devuelva ordenados, no te fies
puede no suceder siempre. Te pondgo un ejemplo el puntero de lectura de
tabla empieza desde el principio, pero imagina que tienes 2 procesadores y
dos usuarios pidiendo exactamente la misma consulta, Select * from clientes,
lo normal es que sql haga un clustered index scan y se recorra el índice y
te devuelva los datos ordenados por clave primaria, pero si el primer
cliente lo ejecutó un poquito antes, sql puede decidir unir la lectura de un
proceso a la lectura del otro, y si por ejemplo el primer proceso está
leyendo la mitad de la tabla, la segunda consulta recibirá primero la mitad
del final de la tabla y despues la primera mitad, Excepto que se especifique
order by, en cuyo caso siempre recibirás los datos ordenados como los hayas
pedidos.

Me alegro que hayas desarrollado tu aplicacio´n en tres capas y que la
migración de una a otra plataforma te resulte tan sencilla, es estupendo,
demuestra un buen ejercicio de desarrollo.
En cuanto a los tres mecanismos de join Hash, loop y merge, Por lo que yo
tengo oido (no comprobado) el optimizador de consultas a partir de sp3 no
usa más hash por que consideran más eficas merge para el caso. En cuanto a
loop y merge son dos estrategias diferentes para solucionar el mismo
problema y depende de que los datos estén ordenados (tengan indices) en uno
u otra tabla y de las estadísticas de sql. El optimizador suele tomar la
mejor decisión a partir de la información que tiene. Si en tu caso el tiempo
de respuesta es tan bueno, realmente el optimizardor usará uno u otro
criterio sin buscar mejores alternativas.
En cualquier caso Julio, usar los Hint para forzar al optimizador a tomar un
camino u otro, es una opción, de hecho sql los tiene para que se puedan
usar, pero generalmente el optimizador toma el mejor camino sin forzarle a
usar una u otra opción.

En cuanto a los comentarios de Leonardo yo estoy parcialmente en desacuerdo
con él, cuando eliges un gestor lo debes, en mi opinión explotar al máximo,
no tendría sentido en Oracle hacer una consulta jerarquica sin usar connect
by prior, solo por que no sea ansi, (por ejemplo) o en Sql-Server no usar
DTS (si te hacen falta) solo por que no estén en el standar. En fin, que tal
y como tu decias si la aplicación es tres capas, cambias una y listo.


Un Saludo
Miguel Egea
http://www.portalsql.com
Microsoft SQL-SERVER MVP.


"Julio C. Briceño R." escribió en el mensaje
news:011801c3584a$da489580$
Saludos,

Solucioné un problema de datos en mi aplicación a forzando
un tipo de combinación loop, en vez de hash en una
consulta de un stored procedures.

Ahora mi siempre sabio amigo, compatriota y MVP no me
recomienda esto pues me explica que eso viola preceptos de
el modelo relacional y que me amarra a TRANSACT SQL lo
cual es malo a la hora de querer camibiar de gestor de
base de datos mi aplicación, ahora.

Mi aplicación está elaborada en tres capas, gracias a lo
cual llegar a tocar la base de datos requiere dos capas
que me evitan que un cambio en una de las dos capas
finales afecten a mi aplicación, pero además traté en lo
posible de utilizar el concepto de independencia de los
datos a través del cual puedo modificar el el propio
sistema de base de datos una capa sin afectar otra.

Probé tratando de migrar a otros gestores de bases de
datos mi aplicación (aunque sigo con SQL Server, no se
preocupen), me di cuenta en Access por ejemplo migro mi
aplicación, creo mis "consultas almacenadas" que simulan
mis stores procedures, quito el "loop" de la consulta,
instalo mi aplicación y listo, si muchos cambios, igual
con Oracle.

Bueno, si alguien leyó esto y lo anterior (de hace como
dos o tres días) y desea transcribir algún comentario,
gracias.

Julio C. Briceño R.
Caracas, Venezuela
Analista de Sistemas
C.I. V-13952301

En tu caso yo haría lo mismo :-D
Un abrazo


Miguel Egea
"Leonardo Azpurua" <l a z p u r u a g (arroba) c a n t v (punto) n e t>
escribió en el mensaje news:%

"Miguel Egea" escribió en el mensaje
news:
> ...
> En cuanto a los comentarios de Leonardo yo estoy parcialmente en
desacuerdo
> con él, cuando eliges un gestor lo debes, en mi opinión explotar al
máximo,
> no tendría sentido en Oracle hacer una consulta jerarquica sin usar
connect
> by prior, solo por que no sea ansi, (por ejemplo) o en Sql-Server no

usar

> DTS (si te hacen falta) solo por que no estén en el standar. En fin, que
tal
> y como tu decias si la aplicación es tres capas, cambias una y listo.

Hola, Miguel:

El "desacuerdo" es sólo aparente, y tiene que ver con el objetivo

principal

del desarrollo.

Si alguien me contrata un desarrollo (o una adpatación) para una

plataforma

basada en SQL Server, lo más probable es que aproveche todas las

capacidades

de SQL Server (tratando siempre de elegir las construcciones más portables
que pueda).

Mi trabajo es el desarrollo de productos de software "barato" para la

venta

a gran escala (esa es la intención: la "gran escala" apenas va por unas 20
licencias al mes). La intención es que si un cliente quiere utilizar SQL
Server u Oracle, pueda hacerlo, lo mismo que uno que se satisfaga con

Access

o con mySQL. Entonces, la estandarización de las construcciones es, para

mi,

un requerimiento casi obsesivo. Lamentablemente, este estilo de trabajo me
impone un "mínimo común denominador" determinado casi siempre por Access
(mySQL tambien es bastante limitado en cuanto a los recursos de
construcción). Los programas implementan mecanismos de extensibilidad, con
scripts en vbs y dlls desarrollados por los usuarios, en los que sí es
posible aprovechar todas las capacidades del manejador (porque cada

cliente

sabe qué plataforma tiene). De hecho, la multiplicidad de gestores es más

un

argumento de ventas (aunque el uso de SQL Server, por ejemplo, te quita

una

cantidad de limitaciones, y te permite una mejora de rendimiento
espeluznante, si lo comparas con Access, por ejemplo) que un valor

práctico

y real.

Siempre se me viene a la cabeza una frase de Bertoldt Brecht cuando

dirigía

teatro: "los actores no sólo deben saber lo que dicen; tambien deben tener
conciencia de lo que no dicen". En programación equivale a decir que no
basta con conseguir UNA solución: hay que hacer rutinariamente un pequeño
esfuerzo adicional para conseguir "la mejor" solución (en ese momento y
lugar determinados). Plantearse, en cada construcción, el reemplazo de
elementos no portables por elementos estandar, no es un mal ejercicio. Si

no

se puede, o si el cambio implica el sacrificio de una capacidad avanzada

del

SGBD que represente una pérdida notable de eficiencia, o si la

construcción

resultante resulta excesivamente ofuscada, o si simplemente ese día estoy

un

poco bruto y no encuentro la equivalencia estandar en un período razonable
de tiempo, pues nada: se deja como está y listo. Pero creo que uno tiene

que

estar consciente tambien de lo que no hace y de los compromisos que toma.

Salud!

Leonardo
[MS MVP - VB]