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