Mirar por favor este query y comentar...

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

[[Lepe]]

Empezado por lbuelvas

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

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

Empezado por lbuelvas

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

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.

[Patricio]

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?