Mirar por favor este query y comentar...

[Neftali [Germán.Estévez]]

Empezado por enecumene

¿Wainting = Waiting?

Pues sigo ...waiting... a que este señor nos consteste, ¿Qué quiere que comentemos?
Porque yo sigo sin tenerlo claro...

[El_Raso]

Gracias a todos por los comentarios.... en realidad lo que ando buscando es la rapidez en la consulta... ahora bien... porque tantas relaciones? porque los datos lo presento en un cxDBgrid de la Quantum que uso (6.38) y necesito mostrar no los codigo (de la provincia, municipio, etc) si no la descripcion.

Como la respuesta de hescopina es que esperaba algunas de ustedes... pero me gustaron muy jocosas...

Y en conclusion lo que quiero es que me comenten de que forma puedo optimizar el query ya que voy a manejar millones de registros en un grid como lo comente mas arriba.

Y gracias a todos por sus comentarios....sigan por favor....

[El_Raso]

Funcionaria igual el query hescopina?, con la forma que propones?

[hecospina]

Pues como lo plantee solo tu puedes probarlo, el caso es que lo que queria mostrar era que no es necesario enlazar las tablas en un misma linea varias veces por ejemplo

Código SQL [-]
LEFT JOIN areadesalud C ON A.codigoregion = C.codigoregion AND A.codigoarea = C.codigoarea

yo pienso que quedaria mejor asi

Código SQL [-]
LEFT JOIN areadesalud C ON A.codigoarea = C.codigoarea

Solo debes enlazar la tabla A con la tabla que contenga el nombre de la otra tabla, las demas relaciones sobran.

Me imagino que en la tabla "areadesalud C" esta en nombre del area?

Otra cosa si puedes garantizar que las llaves foraneas nunca estaran nulas podrias hacerlo con inner join y no con left que es mas lento, prueba y notaras la diferencia

de todos modos sin saber el contenido de las tablas es muy dificil plantear algo mejor que esto

[[Delphius]]

Al igual que hecospina opino que hay algunas relaciones que están de más. Pero para estar seguro, sería útil que nos indicades y nos describas como es la relación entre las tablas, tal vez se pueda conseguir algo más simple.

Por el otro lado, mencionas millones de registros. ¿Al usuario? Sabiendo que son millones de registros sería bueno poder reducir esa consulta... como he dicho antes, si conocieramos más o menos como es el DER podríamos ver como hacer esto de mejor manera.

Saludos,

[[eduarcol]]

y porque, si lo que quieres es el nombre de la provincia y tienes su codigo, deberias utilizar campos lookup en el dataset...

PD. aunque no se como trabajarian con millones de registros, es posible que puedas filtrar esa informacion

[[Lepe]]

Mientras no intente mostrar ese millon de registros en el grid no hay problema, para algo está el optimizador de Firebird y el plan de ejecución de los SQL .

En principio, si pone una restricción where muy fuerte (que solo devuelva 100 registros, por ejemplo), no creo se demore mucho.

Saludos

[El_Raso]

Gracias Nuevamente por contestar...
hescopina y delphius lo que pasa es lo siguiente.... tengo:

CodigoRegion = 1 CodigoRegion=2
CodigoArea=1 CodigoArea=1
CodigoZona=1 CodigoZona=1
Osea que el codigo de area podria repetirse...
Y los tres campos me forman la llave primaria... es por eso que uso el AND. ahora todavia tengo
tiempo de asignar los codigos de Area, Zona y demas de forma automatica... eso me optimizaria
el query... que es lo quen en realidad quiero su opinion de eso....

y gracias a ti lepe tambien.. pero una pregunta...
Cual seria mas rapido en un grid, un campo lookup o una relacion directamente en el query?
Los grid de la Quantum (cxDBgrid) agrupan y filtran por cada columda de manera automatica y son muy rapidos...

Otra cosa lepe que es el optimizador de Firebird y el plan de ejecución de los SQL?

Gracias nuevamente

[[Lepe]]

Para añadir la integridad referencial, puedes basarte en esto si googleas un rato, seguro que encuentras un manual sql decente.

Código SQL [-]
CREATE TABLE EQUIPO(
CLAVEEQUIPO INTEGER NOT NULL,
CLAVEPERSONA INTEGER NOT NULL,
NOMBREEQUIPO VARCHAR(100),
PRECIO FLOAT,
FECHA_ASIGNACION DATE,
PRIMARY KEY(CLAVEEQUIPO),
FOREIGN KEY(CLAVEPERSONA) REFERENCES PERSONAS(CLAVEPERSONA) ON DELETE CASCADE)

Yo he añadido las 3 últimas palabras, así consigues que al borrar una persona en la tabla PERSONAS, se borre todos los registros asociados en la tabla EQUIPOS.

Yo, para evitar claves compuestas, haría un diseño distinto, pero podría ser peor que el tuyo , prefiero que alguien que haya realizado un diseño similar, pueda orientarte.

Personalmente no me gustan los campos LookUp, prefiero hacerlo por sql. He usado pocas veces esos tipos de campos y las veces que lo hice, acabé quitándolos.

El plan de ejecución, es la forma interna en que Firebird une las tablas de tu sql, para llegar a formar el resultado total (la unión de todas). El optimizador es el encargado de:
- mirar los campos que has seleccionado
- ver los índices de cada tabla y elegir el más adecuado para tu sql actual.
- unir las tablas en un orden determinado para que el proceso sea el más rápido.
- chequear la restricción where de tu sql para aplicarla cuanto antes y así, hacer la union de las tablas con los mínimos registros posibles (obviamente cuantos más registros, más tarda la consulta en generarse).

FlameRobin es parecido a IB Expert y te muestra en un esquema ese plan de ejecución. En consultas muy concretas, es necesario modificar el plan manualmente para optimizarla al máximo. También es bueno echarle una visual no más para aprender .

Saludos.