FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Gracias a Cadetill y Mick por responderme.
Probe: select * from clientes.db c inner join bene.db x on x.idcliente=c.idcliente Tiempo +- 20 segundos select * from bene.db b, clientes.db c where b.idcliente=c.idcliente Tiempo +- 20 segundos. Cuando digo como funciona SQL quiero decir como son evaluadas las sentencias (si empieza por la tabla de la izq. hacia la derecha ,de la der. A la izq, si evalúa primero las tablas que tienen cláusulas “where”, o por donde empieza cuando hay mas de dos tablas. Con respecto al tiempo no se si 5 segundos es mucho y 20 son una eternidad, también hay que tener en cuenta que las tablas no las tengo en mi disco rígido, sino que están en el disco del servidor con la red de por medio. En ambas tablas tengo un índice primario en el campo idcliente. Cadetill mira estas dos sentencias: A) select * from bene.db b left outer join bene.db x on x.idcliente=b.idcliente left outer join clientes.db c on c.idcliente =b.idcliente Tarda +- “5” segundos. B) select * from bene.db b left outer join clientes.db c on c.idcliente =b.idcliente Tarda +- “20” segundos. Cuando repito la tabla bene por 2º vez en el join de la consulta “A”, la consulta tarda 15 segundos menos, es lo que me llama poderosamente la atención, cuando lo lógico seria usar la sentencia “B”. |
#2
|
|||
|
|||
Usando la misma tabla, la verdad es que no tiene mucho sentido esta diferencia en el tiempo, todo al contrario, creo que tendría que tardar más ya que ha de hacer una unión (que por otro lado será rápida, pero no para rebajar tiempo)
Si fuese como en el primer mensaje, es decir, que unes 3 tablas, sí que podría ser, ya que una de las uniones puede devolver pocos registros y, así, acelerar la segunda unión. Según tengo entendido, las uniones entre tablas se hacen de fuera hacia dentro, es decir, primero evalua la primera join, luego la segunda,..... pero ya digo, la valuación de la join cuesta un tiempo (aunque sean milisegundos) por lo que no tiene mucho sentido que reste A ver si alguien con más experiencia que yo en el Local SQL (que es el que hace servir Paradox) nos puede informar algo más al respecto |
#3
|
||||
|
||||
no se cuan rapido es Paradox, pero revisa si las tablas tienen definidos indices en el campo idcliente y si tienen clave primaria. esto es muy importante para que las consultas se ejecuten rapidamente.
ten en cuenta que la capacidad de la red influye en el tiempo de respuesta. vuelve a ejecutar las consultas pero de esta forma: selec null from ... esta consulta solo devuelve un registro nulo. asi consigues que el tiempo de respuesta no este influenciado por la red.
__________________
“Plantad la semilla de la avaricia en la infértil tierra de la estupidez y obtendreis la bella flor de la mierda” (Confucio) |
|
|
|