FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
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. |
#2
|
||||
|
||||
Gracias por la orientación.
|
#3
|
||||
|
||||
Cita:
POBLACION tiene como clave primaria precisamente esa. MESAS tiene como clave primaria CODPRV, CODIGO. Además tiene otro índice con CODPRV y MUNICIPIO. |
#4
|
||||
|
||||
Ahora sí. Muchísimas gracias.
|
#5
|
||||
|
||||
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 |
#6
|
||||
|
||||
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. |
#7
|
||||
|
||||
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. |
#8
|
||||
|
||||
Al descargar el fichero te he pedido acceso.
En cuanto pueda descargarlo haré algunas pruebas para ver qué contienen las tablas... |
#9
|
||||
|
||||
He estado mirando las tablas...
Primera parte La primera duda es cómo se unen mesa, poblacion y numelectos. He inferido que mesas.codigo, poblacion.municipio y numelectos.circunscripcion es el mismo campo y lo he utilizado para los joins. La segunda duda es qué es proceso? He inferido que se trata de diferentes votaciones y he estado utilizando la número 42. Segunda parte. Lo primero que necesitas antes de hacer las acumulaciones es la tabla con todos los datos necesarios unidos mediante JOIN / LEFT JOIN.
Este SQL devuelve 113511 registros.
Ahora agrego el where para limitar los datos a tratar. En este caso he elegido alguno que devuelve datos y que hemos hablado en este hilo Este SQL devuelve 8 registros.
Final Ya tenemos los datos. Ahora solo tenemos que agruparlos y ordenarlos.
Dos formas de evitar que salgan registros "sin electos".
|
|
|
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 |
|