FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
||||
|
||||
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".
|
#2
|
||||
|
||||
PD.
Después de ejecutar el script, todo iba muy lento. He tenido que recaclular los índices para que todo vaya bien. IbExpert tiene la opción de ir a DataBase-> Recompute celectivity of all Indeces Básicamente recorre los índices de la base de datos y ejecuta SET STATISTICS INDEX [IndexName]:
|
#3
|
||||
|
||||
Cita:
Por otra parte, sobre la velocidad de ejecución he de decirte que para sacar todos los municipios a mi en SQL Manager me ha tardado 62 milisegundos. Únicamente las lecturas de la tabla mesas se hacen sin usar índices; tengo que ver por qué. |
#4
|
||||
|
||||
A mi también me va muy rápida la consulta, pero al principio los índices estaban desbalanceados (supongo que por el insert masivo del script) y todos tenínan un valor de 1 (o 0, no recuerdo bien).
Las estadísticas de los índices es una parte importante de lo que mira el planificador de SQL al hacer los JOINS. Esto te devuelve las estadísticas de los índices y deberían tener valores lo más bajo posibles sin ser 0.
Esto es lo que me devuelve ahora, después de ejeructar el "SET STATISTICS [indice]". Código:
RDB$RELATION_NAME RDB$INDEX_NAME RDB$STATISTICS ----------------- -------------- -------------- MESAS DISMES 0,001355013577 MESAS MUNMES 0,009803921916 MESAS PK_MESAS 0,001355013577 NUMELECTOS PK_NUMELECTOS 0,001915708766 PARTIDOS PK_PARTIDOS 0,018518518656 POBLACION PK_POBLACION 0,000017048846 RESULTADOS PK_RESULTADOS 0,000008809486 |
#5
|
||||
|
||||
Es decir que cuanto más bajo sea ese valor mejor está el índice. No lo sabía; todos los días se aprende algo.
Otra cosa: Si ejecuto el query para que me saque todos los municipios, cambiando la línea por me ocurre una cosa que, al menos a mi, me llama la atención. Table Operations: +----------------- Table Name | Index | Non-Index | reads | reads +--------------------------+-----------+ MESAS| 0 | 1.476 | NUMELECTOS| 4.534 | 0 | PARTIDOS| 5.786 | 0 | POBLACION| 1.476 | 0 | PROVINCIA| 5.786 | 0 | RESULTADOS| 5.786 | 0 | La tabla mesas tiene tres índices: la clave primaria (CodPrv + Codigo) y dos índices: uno por CodPrv y Municipio y el otro por todos los datos identificativos de la mesa. Y dado que las búsquedas en las que interviene la tabla Mesas se hacen por alguno de los campos indexados, prinicipalmente municipio y código de mesa), ¿por qué no se usan los índices para esas búsquedas? |
#6
|
||||
|
||||
El número de los índices indica cuan específico es. Entiéndase cuan único es cada registro.
Si tienes una tabla ARTICULOS (EMPRESA, ARTICULO) y tienes los valores Código:
1, ART1 1, ART2 1, ART3 1, ART4 un índice por ARTICULO tendra estadística = 0,25, indicando que "se repite poco" (en este ejemplo nada) en todos los registros. Por lo tanto, si el planificador de JOINs tiene la opción de usar uno de estos dos índices, preferirá el de artículo. Nota: Un índice por EMPRESA+ARTICULO también tendra estadística = 0,25, indicando que "se repite poco" (en este ejemplo nada) en todos los registros. Creo que estás haciendo el SQL de forma incorrecta. Si no quieres filtrar por municipio, debes eliminar esa línea del WHERE.
Suposición 1 - Agregas lo que mencionas al WHERE. Si haces lo que que mencionas, estarás diciendo que muestre los registros donde el municipio de la mesa sea el municipio de la poblacion. Esto ya está garantizado por los JOINs join mesas m on m.codprv = r.codprv and m.codigo = r.mesa join poblacion po on p.codprv = po.codprv and m.municipio = po.codigo Solo le estarás complicando la vida al planificador.
Suposición 2 - Quitas "m.municipio = po.codigo" del JOIN . Si haces esto, estás cambiando los datos sobre los que haces los cálculos. En ese caso, si tenemos en cuenta solo las tablas MESAS y POBLACION sería
En este caso cada mesa se uniría con todas las poblaciones y tendrías muchísimos registros más. Prueba estos SQL:
Última edición por duilioisola fecha: 14-11-2023 a las 20:01:47. |
#7
|
||||
|
||||
Muchísimas gracias. Tus explicaciones me enseñan muchas cosas que desconozco.
|
#8
|
||||
|
||||
Perdona por no haberte explicado las relaciones, pero has acertado en todas.
|
|
|
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 |
|