FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
Transformado a JOINS
|
#2
|
||||
|
||||
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.
|
#3
|
||||
|
||||
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. |
#4
|
||||
|
||||
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. |
#5
|
||||
|
||||
Gracias por la orientación.
|
#6
|
||||
|
||||
Cita:
POBLACION tiene como clave primaria precisamente esa. MESAS tiene como clave primaria CODPRV, CODIGO. Además tiene otro índice con CODPRV y MUNICIPIO. |
#7
|
||||
|
||||
Ahora sí. Muchísimas gracias.
|
#8
|
||||
|
||||
Pues no sé lo que pasa. El query funciona pero...
Si ejecuto el query como me ha propuesto duilioisola me da este resultado: No veo de donde sale esa suma de votos que, por otra parte, es el único campo que se calcula mal. Por citar sólo un ejemplo el municipio de Alcázar de San Juan tiene un censo electoral de 23670 personas y los votos emitidos fueron 16192. Sin embargo la suma de votos que hace el query es la que se ve ahí. Sin embargo si ejectuto este query sólo para ese municipio: El resultado es este, que es el correcto No veo por qué se multiplican los datos. He comprobado que si divido las resultados de ambos querys de los partidos que tiene electos en todos los casos sale la misma cifra: 44 |
#9
|
||||
|
||||
He estado probando añadiendo y quitando trozos del query original y descubierto que el problema viene con el último LEFT JOIN:
Si se deja, salen mal los datos. |
#10
|
||||
|
||||
Cada vez estoy más desanimado con este query, y mira que pintaba bien.
He hecho la prueba con left join resultados y con join resultados y eliminando resultados en la tabla NumElectos para que de un municipio no hubiera esos campos pero sí resultados. Y con las tablas completas sale este resultado: pero si suprimo lo que he comentado sale esto aunque en la tabla resultados siga habiendo datos del municipio en cuestión (en este caso el 175). No lo entiendo: con LEFT JOIN ¿no deberían salir datos para ese valor? No sé que estoy haciendo mal o no entendiendo. En el enlcae https://drive.google.com/file/d/1F3V...ew?usp=sharing hay un fichero TABLAS.RAR que tiene el script para crear y llenar las tablas implicadas en el query. |
|
|
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 |
|