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

:)

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?:eek: 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,

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

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

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

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 :eek:, 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.

Hombre!, qué alegrías; Al fin apareciste... ;)

En general, para obtener rapiudez, yo te recomendaría (algunas cosas ya las han comentado):
* Utilizar las menos JOIN's posibles en la consulta (las necesaria)
* No mostrar más campos de los necesarios.
* INNER JOIN infinitamente más rápido que el resto (LEFT, RIGHT,...) siempre que sean posibles.
* Indices únicos (PK) en los campos que utilices para las JOIN. Si utilizas claves, simpre numéricas y simples (no varios campos).
* En el caso de SQL server (por ejemplo) se pueden definir indices "clústered" que aumentan la velocidad (1 por tabla). Si hay algo similar utilízalo.
* Revisa el plan de ejecución (si tienes posibilidad) para ver los cuellos de botella de tu consula. A partir del plan concreto, se puede "afinar" un poco más...

En cuanto al grid de las Quantum, recorder que es muy bonito, pero nos es de los más rápidos en cargar. Recuerda que los Grid de las Quantum tienen dos modos de trabajo, uno que cargan datos por bloques y otro que carga todos los datos. Piensa bin el que vas a usar, contando que el que carga por bloques desactiva las agrupaciones, ordenaciones y filtros (que tan bonitos son en el Grid de las Quantum).

Por ultimo olvídate de esto: "...voy a manejar millones de registros en un grid.".
Un Grid está pensado para mostrar un conjunto de registros que un usuario pueda manejar. Mostrar más de 2000 registros enun DBGrid es inútil para un usuario e ineficiente. No quiero ni pensar (dudo que puedas) mostrar millones. Utiliza filtros, TOP,....

yo la duda que tengo es, que se guarda en este campo??

:eek:

Gracias neftali por tu comentario.... en verdad los de millones de registro es para hacer consulta... creo que nunca lo llegaria a mostrar en un grid... Gracias nuevamente..
Una cosa mas neftali... mirando tu el query es posible usar inner en vez de left... seria igual el resultado?...
Todas las tablas que utilizo en las relaciones solo tienen 2 campos (y nunca null) y uso las relaciones solo para desplegar la descripcion del registro ya que solo gurdo el codigo en la tabla principal del query.




gmontes... ese campo es la descripcion (o el nombre) de un campo de una tabla llamada UNAP... en la tabla ficha de familia solo guardo el codigo un smallint y con la relacion (con el join) agrego al query el campo Nombre o la Descripcion del registro que me interesa de esa tabla...

Si no tienes valores nulos, LEFT o RIGHT debería devolver el mismo resultado que INNER. Si es así, utiliza INNER.

Cuando la llave foranea es mandatoria, es decir, que tiene obligatoriamente un valor que coincide con un valor en la otra tabla, puedes utilizar inner join o left outer join (algunos manejan left join simplemente).

Deben hacerse pruebas con una opcion o con la otra, no recomiendo el rigth join en lo personal me ralentiza casi siempre las consultas.

Casi siempre en las bases de datos que he diseñado obtengo ventajas en velocidad con el left join versus el inner join.

Tú lo has dicho, del diseño viene todo ;), has hecho bien con incluir el "casi siempre" y no generalizar.

Saludos

:eek::eek::eek::eek:
La verdad que es la primera vez que lo oigo y todavía no acabo de entender muy bien cómo puede ser.
¿Hablamos de Bases de datos de escritorio?
Me gustaría ver los plabnes de ejecución de la misma consulta con LEFT JOIN y con INNER JOIN.

Un saludo.

coincido en cuanto al inner y left
 

en mi poca experiencia hay una gran diferencia a favor del inner que el left join, ahora para ir achicando y que no quede una consulta tan grande no podrias hacer algunas views para ir tomando algunos datos por separado y te quedaria una consulta mas pequeña y facil de relacionar, creo no?