Mirar por favor este query y comentar...

[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.

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

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

Empezado por El_Raso

...ando buscando es la rapidez en la consulta...

porque los datos lo presento en un cxDBgrid de la Quantum

quiero es que me comenten de que forma puedo optimizar el query ya que voy a manejar millones de registros en un grid

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

[gmontes]

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

I.nombreunap,

[El_Raso]

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...

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

Empezado por El_Raso

...mirando tu el query es posible usar inner en vez de left... seria igual el resultado?...

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

[lbuelvas]

Empezado por Neftali

* INNER JOIN infinitamente más rápido que el resto (LEFT, RIGHT,...) siempre que sean posibles.

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.