 |
Club Builder
Foro de C++Builder en español
|
| Ver tema anterior :: Ver tema siguiente |
| Autor |
Mensaje |
Manolo(er_lolo)
Capt
Registrado: 28 Jul 2003Mensajes: 172Ubicación: Salamanca
|
 Publicado: Lun 16 Feb, 2004 9:08 am Asunto: Mejorar rendimiento (Velocidad) |
 |
|
Wenas tengo un pequeño problema con las consultas SQL, el problema es que el programa tarda bastente en realizar las consultas mediante SQL que realizo.
Hay alguna forma de incrementar la velocidad?.
Las tablas son access. (Obligado).
Un Saludo y gracias de antemano. |
|
| Volver arriba |
|
 |
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Lun 16 Feb, 2004 10:04 am Asunto: |
|
|
Cuantas tuplas tienen las tablas ? Si son muy grandes deberías cambiar el sgbd, pues según yo he leido (NO LO HE COMPROBADO) en el momento que el número de tuplas en las tablas crece bastante, ACCESS tiene un comportamiento muy pobre en cuanto al rendimiento, te diría si has introducido indices, pero tampoco sé si ACCESS soporta indices sobre tablas, si es así cuantos soporta y sobre que campos los soporta. De todos modos a mi me ha pasado algunas veces, que una sentencia SQL mal hecha puede hacer eterno el calcular su resultado, incluso en servidores más potentes, y a veces es mejor crear una vista con un resultado intermedio y realizar la consulta sobre ella, luego siempre la puedes borrar, pues la puedes crear antes de realizar la consulta, realizas la consulta, lees los datos y la borras, esto puede hacerse en un mínimo de segundos, e incluso es más rapido que a lo mejor hacer la sentencia SQL original para obtener el mismo resultado.
Ciao y suerte.
_________________
OJO!! Ya tenemos subforo de Bases de Datos!!
Gracias a los admins. |
|
| Volver arriba |
|
|
Manolo(er_lolo)
Capt
Registrado: 28 Jul 2003Mensajes: 172Ubicación: Salamanca
|
| Publicado: Lun 16 Feb, 2004 10:23 am Asunto: |
|
|
Weno, la verdad es q las tablas si son grandes, de momento tiene 175.000 registros mas o menos, y 124 campos.
Lo de los indices no tengo ni idea de si access los tiene, la tabla ya me la han dado exa, (Si no no lo hago con access ni de coña).
La consulta en si es la siguiente :
| Cita: | Sentencia = "SELECT Albaran.NumeroAlbaran, Albaran.SerieAlbaran,Albaran.CodigoCliente, LineasAlbaran.FechaAlbaran, LineasAlbaran.BaseImponible, LineasAlbaran.vcc, Clientes.vcr, LineasAlbaran.Unidades";
Sentencia+= " FROM (Albaran INNER JOIN LineasAlbaran ON (LineasAlbaran.Ejercicio = Albaran.Ejercicio) AND (Albaran.SerieAlbaran = LineasAlbaran.SerieAlbaran) AND (Albaran.NumeroAlbaran = LineasAlbaran.NumeroAlbaran)) INNER JOIN Clientes ON Albaran.CodigoCliente = Clientes.CodigoCliente";
Sentencia+= " GROUP BY Albaran.NumeroAlbaran, Albaran.SerieAlbaran, Albaran.CodigoCliente, Albaran.FechaAlbaran, Albaran.BaseImponible, LineasAlbaran.vcc, Clientes.vcr, LineasAlbaran.Unidades"; |
Donde Sentencia es una variable AnsiString en la que guardo la sentencia SQL.
¿ como se haria la vista ?
salu2. |
|
| Volver arriba |
|
|
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Lun 16 Feb, 2004 11:10 am Asunto: |
|
|
No hace falta que digas más Manolo, el número de registros para una unica tabla ACCESS es descomunal, más 124 campos son muchos campos también!!
Quiero pensar que a las tablas se les habrá aplicado alguna forma normal, por lo menos hasta la 3ª o Boyce y Codd. Aun así 124 campos para una unica tabla repito que son muchos, sino no has aplicado bien por conocimiento o bien abstractamente las formas normales más basicas, puedes tener información repetida y violar varios principios que se deben conocer sobre las BD.
175.000 registros para una única tabla son muchos para Access, te sugiero te pases a un SGBD más potente.
La vista Manolo(er_lolo) se hace sobre parte de la consulta, te pongo un ejemplo tonto para que te hagas a la idea (es muy tonto), pero por lo menos te harás mejor a la idea.
Imaginate que tenemos una tabla de clientes y una tabla gastos de clientes, entonces imaginate que queremos obtener los nombres y codigos de clientes que superan las 1000 euros en gastos. Yo me puedo crear una vista con los siguientes campos, nombre cliente, codigo cliente, gasto total, donde la vista se crea por ejemplo haciendo un
| Código: |
CREATE VIEW gastos_clientes (codigo_cliente, nombre_cliente, gastos) AS
SELECT codigo_cliente, nombre_cliente, SUM(GASTOS) as gastos
FROM clientes, gastos
GROUP BY codigo_cliente
|
Como puedes ver creo una vista (se puede hacer en tiempo de ejecución en cualquier momento, donde la vista contendrá 3 campos, uno para el cidog, nombre y gastos, como ves los gastos para un cliente los calculo llamado a la función agregada que me realizará una suma de todos los campos del mismo codigo cliente (condición de agrupación). Una vez creada funciona igual que si fuera una tabla, puedes consultar con una sentencia SQL, por ejemplo:
| Código: | SELECT nombre_cliente AS nombre
FROM gastos_clientes
WHERE gastos > 1000
|
Incluso puedes usar estas vistas en otras consultas o subconsultas.
Hay que decir que debes enterarte de si Access soporta Vistas pues no todos los SGBD soportan vistas, aunque sí la mayoría, si es así aun así deberás ver las sentencias concretas, aunque el SQL92 es el standard que mayormente se encuentra implementado en casi todos los SGBD.
Espero que te haya servido el post, solo son unas aclaraciones al respecto de tu post en ningun momento te lo soluciono, tu deberías plantear lo siguiente, empieza a ejecutar tu consulta con menos cosas y mira que tiempo tarda en ejecutarse conforme veas que este tiempo crece llega a un compromiso y entonces introduce vistas hasta donde tu estimes oportuno, el resto de la consulta ya lo haces sobre la vista que es muchísimo más rapido, piensa que quizás en la tabla original tengas 175.000 registro y en la vista dependiendo de lo que hagas puedes tener bastantes menos, con lo que agalizas todo.
Repasa también la tabla, y mira algo en internet donde te hable sobre la 1ª, 2ª y 3ª forma normal, pues son las más basicas, una vez que entiendas lo que hacen y para que sirven no hace falta que aplices el algoritmo para pasar a esa forma normal, (aunque es mecánico es una pesadez), las tablas aun así, deben representar entidades conceptuales, es decir si tengo una tabla clientes, no debe tener nada de la tabla proveedores, albaranes, etc, cada tabla debería corresponderse con 1 entiedad, a excepcion de ciertas tablas que son introducidas para hacer correspondencias entre dos o más tablas. Hay unos libros excelentes a mi juicio sobre diseño relacional, a mi me gustan mucho los de "De Miguel y Piatini" - Diseño de Base de datos relacionales, tienes una edición del 1993 y otra del 1999 cualquier de las dos es un excelente documento. Principalmente te sugeriría también que cambies de motor de BD si de verdad tienes 175.000 registros me parece que Access se te queda cortisimo, además aunque funcione con tantos registros, te estás perdiendo un mundo de posibilidades y mejoras en rendimiento de los SGBD potentes, Firebird, Interbase, MySQL, SQL Server, Oracle, etc... Además de que algunos de ellos son gratis incluso para las empresas. Si el acceso a BD lo has hecho con BDE, aunque no ganes todo el cambio a otro SGBD, ganarás en eficiencia bastante incluso con el BDE, sobretodo si en vez de usar TTables usas TQuerys para el mismo fin.
Ciao y suerte.
_________________
OJO!! Ya tenemos subforo de Bases de Datos!!
Gracias a los admins. |
|
| Volver arriba |
|
|
Manolo(er_lolo)
Capt
Registrado: 28 Jul 2003Mensajes: 172Ubicación: Salamanca
|
| Publicado: Lun 16 Feb, 2004 11:27 am Asunto: |
|
|
Gracias por tu respuesta, intentare mejorar la velocidad con las vistas, lo de la tabla en access ha sido obligado, de momento con las tablas q mas he trabajado ha sido con DBade, pero estoy intentando ponerme un poquito al dia con Firebird para pasarme a estas.
No sabreis de algun manual de introducción a Firebird.
Gracias por todo. |
|
| Volver arriba |
|
|
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Lun 16 Feb, 2004 11:27 am Asunto: |
|
|
Se me olvidaba decir que los indices te pueden ayudar a hacer tus consultas más eficientes, yo no sé si Access los soporta y cuantos por tabla soporta, pero si los soporta, intenta añadir indices a los campos que más suelas utilizar en las tablas y que no sean clave, pues estos por estos el hecho de serlo ya tienen indices, por ejemplo si en esa consulta usas campos que no sean claves podrías crear un indice sobre ellos, eso te ayudará en las consultas, aunque también hay que saber que penaliza un poco las inserciones y modificaciones, como siempre hay que llegar a un compromiso, entre lo que se quiere alcanzar y lo que se tiene.
Ciao.
_________________
OJO!! Ya tenemos subforo de Bases de Datos!!
Gracias a los admins. |
|
| Volver arriba |
|
|
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Lun 16 Feb, 2004 11:31 am Asunto: |
|
|
Por ahora no hay ningun manual así publico sobre Firebird, hay algunos libros japoneses y alemanes creo, la documentación de Firebird está en desarrollo, por ahora lo unico útil es el manual de instalación y configuración que además lo tienes traducido al castellano, te sugiero si quieres empezar con Firebird, que te cogas la documentación "full package" de Interbase 6.0 OS, pues recordemos que Firebird se basa en el, si te coges esta documentación y el manual de instalación y configuración tendrás un buen punto donde comenzar.
La documetnación de Interbase 6.0 OS es completisima habla de todo tanto del SQL soportado, como el API, seguridad, etc, luego con el manual de instalación y configuración de Firebird 1.5, te vienen todos los cambios realizados hasta la fecha y los nuevos metadatos y majoras introducidas en Firebird, lo único que te falta es decidir que compos utilizas para acceder al servidor.
ciao.
_________________
OJO!! Ya tenemos subforo de Bases de Datos!!
Gracias a los admins. |
|
| Volver arriba |
|
|
Manolo(er_lolo)
Capt
Registrado: 28 Jul 2003Mensajes: 172Ubicación: Salamanca
|
| Publicado: Lun 16 Feb, 2004 12:03 pm Asunto: |
|
|
Sobre los indices, la verdad es que no se si access los tiene, pero aunque asi fuera, lo peor de todo es que la base de datos q tengo no la puedo modificar.
Sobre firebird, haber si tengo tiempo y le exo un vistazo.
salu2. |
|
| Volver arriba |
|
|
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Lun 16 Feb, 2004 12:20 pm Asunto: |
|
|
A que te refieres con que no la puedes modificar ? Porque cuando creas una vista realmente estás modificando la BD, aunque no alteres ningun dato sobre las tablas, lo mismo sucede con los indices, puedes crear un indice antes de hacer una consulta, aunque esto tiene poco fuste y perderás tiempo creando y destruyendo los indices, aun así puedes crear cualquier indice en cualquier momento sin que eso afecte a los datos.
Ciao.
_________________
OJO!! Ya tenemos subforo de Bases de Datos!!
Gracias a los admins. |
|
| Volver arriba |
|
|
Manolo(er_lolo)
Capt
Registrado: 28 Jul 2003Mensajes: 172Ubicación: Salamanca
|
| Publicado: Lun 16 Feb, 2004 12:58 pm Asunto: |
|
|
OK, No habia creado nunca indices en tiempo de ejecucion  . |
|
| Volver arriba |
|
|
XyVy
Master
Registrado: 25 Ago 2002Mensajes: 557Ubicación: Murcia (España)
|
| Publicado: Lun 16 Feb, 2004 3:11 pm Asunto: |
|
|
Ya te digo que no te aconsejo para nada que se cree un indice para hacer una consulta y luego borrarlo, es absurdo y al final tardarás más tiempo, pero si te digo que en cualquier momento se puede crear un indice, para usarlo de ahí en adelate, mirate la sentencia CREATE INDEX ... lo puedes ejecutar en cualquier Query y dispondras de el desde el mismo momento en que se cree, haz pruebas de la Query, usando varias posibilidades, Vistas, Indices, una mezcla de estos, y mira con cual de ellas mejoras más, y entonces puedes ir perfilando cosas.
ciao y suerte.
_________________
OJO!! Ya tenemos subforo de Bases de Datos!!
Gracias a los admins. |
|
| Volver arriba |
|
|
|
|
No puedes publicar temas nuevos en este foro
No puedes responder a temas en este foro
No puedes editar tus mensajes en este foro
No puedes borrar tus mensajes en este foro
No puedes votar en las encuestas de este foro
|
© 2002–2026 Club Builder · Funciona con phpBB.
|
FAQ
Buscar
Miembros
Grupos de Usuarios
Registrarse
Perfil
Entra para ver tus mensajes privados
Entrar
