FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#21
|
|||
|
|||
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
yo pienso que quedaria mejor asi
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 |
#22
|
||||
|
||||
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, |
#23
|
||||
|
||||
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
__________________
...Yo naci en esta ribera del arauca vibr@d0r Soy hermano de la espuma, de la garza, de la rosa y del sol... Viva Venezuela |
#24
|
||||
|
||||
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
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#25
|
|||
|
|||
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 |
#26
|
||||
|
||||
Para añadir la integridad referencial, puedes basarte en esto si googleas un rato, seguro que encuentras un manual sql decente.
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.
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#27
|
||||
|
||||
Hombre!, qué alegrías; Al fin apareciste...
Cita:
* 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,....
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#28
|
||||
|
||||
yo la duda que tengo es, que se guarda en este campo??
Cita:
__________________
Todos llevamos nuestros demonios a cuestas.. |
#29
|
|||
|
|||
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... |
#30
|
||||
|
||||
Si no tienes valores nulos, LEFT o RIGHT debería devolver el mismo resultado que INNER. Si es así, utiliza INNER.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#31
|
|||
|
|||
Cita:
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.
__________________
Luis Fernando Buelvas T. |
#32
|
||||
|
||||
Cita:
Saludos
__________________
Si usted entendió mi comentario, contácteme y gustosamente, se lo volveré a explicar hasta que no lo entienda, Gracias. |
#33
|
||||
|
||||
Cita:
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.
__________________
Germán Estévez => Web/Blog Guía de estilo, Guía alternativa Utiliza TAG's en tus mensajes. Contactar con el Clubdelphi P.D: Más tiempo dedicado a la pregunta=Mejores respuestas. |
#34
|
|||
|
|||
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?
|
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Ayuda por favor para correr un query en Delphi a una base de datos en Mysql | charlyfitlh | MySQL | 10 | 01-11-2007 20:28:49 |
Problema con DBGrid y Query...Ayuda por favor! | AFilth | Varios | 2 | 03-11-2005 16:42:17 |
Por favor, Ayuda en Query y paradox | CarlosHernandez | Conexión con bases de datos | 1 | 25-07-2005 16:20:52 |
como quedaria el SQL para este Query?? | JCarlos | Conexión con bases de datos | 2 | 15-11-2004 12:59:28 |
|