FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
A vueltas con un query
Y va el tercer hilo (Filtrar resultados en un query y ¿Y por qué no funciona el ORDER BY?) con el mismo problema. He encontrado otra manera de sacar los resultados y esta vez funciona:
Las tablas implicadas en el query son estas:
Puede darse la circunstancia de que no se hayan grabado o calculado todavía los electos (tabla NumElectos) para una determinado proceso y/o circunscripción. He hecho la prueba borrando todas las entradas de esa tabla para un determinado proceso y al ejecutar el query no me devuelve ninguna fila aunque el resto de tablas implicadas sí tengan información. Yo tenía la idea que con el LEFT JOIN se obtenía resultados aunque en esa tabla no hubiera información que se ajustara a las condiciones. Si estoy equivocado os rogaría que me iluminaráis. Gracias. |
#2
|
||||
|
||||
En este caso debes agregar la condición a la parte de la UNION entre tablas (ON ...)
De esta forma hace el JOIN y como es de tipo LEFT no importa que no tenga datos... Algo así... pero tendrías que utilizar un LEFT JOIN para RESULTADOS porque filtras por mesas que estén en la circunscripcion.
Yo te recomentadría utilizar JOIN / LEFT JOIN para unir las 4 tablas y no mezclar diferentes formas de hacerlo. |
#3
|
||||
|
||||
Transformado a JOINS
|
#4
|
||||
|
||||
Gracias por la sugerencia. Tengo que estudiarla porque tal cual me la has planteado he tendio que abortar la ejecución porque llevaba 10 minutos sin sacar nada y tal como he planteado el query yo se ejecutaba en menos de 1 segundo.
|
#5
|
||||
|
||||
Gracias por la idea. He estado probando y si ejecuto el query tal como me propones, como te he dicho antes, se eterniza y tengo que cancelar la ejecución porque llevando 10 minutos no ha sacado nada, y es lógico porque, a mi modesto entender, trataría de sacar todas las filas de la tabla poblacion; y si hago un pequeño cambio:
Si no hay datos en NumElectos no saca nada. Seguiré investigando, pero ya mañana. |
#6
|
||||
|
||||
Si haces LEFT JOIN con numelectos, también debes hacer LEFT JOIN con las tablas que se unen a ella.
Si numelectos no tiene registros, C.CIRCUNSCRIPCION será nulo y el JOIN con población no devolverá nada.
Para que no se haga eterno deberás tener índices para los campos con los que haces el JOIN. He visto que tienes PKs, que generan índices para estas tablas, pero que quizás no sean óptimos. Por ejemplo Quizás NUMELECTOS debería cambiar el orden de los campos de la PK a CODPRV,PROCESO,TIPO,[PARTIDO <- , -> CIRCUNSCRIPCION],CARGO para que se utilice mejor en el LEFT JOIN. POBLACION debería tener un índice por CODPRV,CODIGO. MESAS no tiene ningún índice. |
#7
|
||||
|
||||
Gracias por la orientación.
|
#8
|
||||
|
||||
Cita:
POBLACION tiene como clave primaria precisamente esa. MESAS tiene como clave primaria CODPRV, CODIGO. Además tiene otro índice con CODPRV y MUNICIPIO. |
#9
|
||||
|
||||
Ahora sí. Muchísimas gracias.
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
a vueltas con los servidores de datos | anubis | Varios | 11 | 13-01-2010 09:37:42 |
Dando vueltas con las capas | CHiCoLiTa | Providers | 0 | 24-01-2006 12:09:55 |
Dandolo vueltas a un indice | gario | Oracle | 0 | 17-03-2005 14:04:47 |
|