Al hacer una consulta, el motor de la base de datos utilizará (siempre que
existan) los índices que considere oportunos para obtener el mejor
rendimiento (no es necesario que lo hagas explícitamente por código). Por
ejemplo, una consulta del tipo:
SELECT * FROM Pedidos INNER JOIN Proveedores ON Pedidos.IdProveedor =
Proveedores.IdProveedor
Sin los campos «Pedidos.IdProveedor» y «Proveedores.IdProveedor» indexados,
resultaría extremadamente ineficiente (se tendría que recorrer ambas tablas
completas secuencialmente para encontrar los registros coincidentes). Si
indexas ambos campos, el motor de la base de datos utilizará ésos índices y
la consulta se resolverá mucho más rápidamente.
Lo mismo ocurriría con tu filtro de fecha. Por ejemplo:
SELECT * FROM Pedidos WHERE FechaPedido BETWEEN '01/01/2002' AND
'31/12/2002'
(ésta consulta sería equivalente a tu .Filter = FechaPedido BETWEEN
'01/01/2002' AND '31/12/2002')
Si «FechaPedido» no estuviese indexado, se tendría que recorrer toda la
tabla para encontrar los registros cuya fecha está comprendida en ése
intervalo.
En resumen, indexa los campos que aparecen en tu INNER JOIN y en tus WHERE o
Filter (por cierto, siempre que sea posible, indéxalos «Sin duplicados»,
para un mejor rendimiento aún). De todos modos, un exceso de índices puede
resultar contraproducente, al ralentizar tus operaciones de inserción,
modificación y eliminación de registros (al tener que reconstruir los
índices respecto a los cambios realizados), aunque, en un entorno donde
primen las consultas a la edición de registros, puede que ésto no suponga
demasiado inconveniente
MAS
===
segun lo que te dijeron todos los compañeros sobre si tenes que
crear nuevos indices para acelerar las consultas si trabajas con Access te
envio una tecnica para saber como Access arma el PLAN de ejecucion, esto es
muy importante porque te dice que indices utiliza Access y con esto podes
ver si los indices que creastes realmente sirven, a mi me paso con un indice
y gracias a esto me di cuenta cambie el indice y la velocidad se incremento
notablemente.
Lo que tenes que hacer es entrar a la registry de la computadora y llegar
hasta la rama
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Debug
Agregas la entrada JETSHOWPLAN y le pones como valor ON, esto hace que el
jet te deje en un archivo el plan de ejecucion de cada sentencia de SQL, el
archivo que te deja es el showplan.out dentro del directorio en donde esta
la base de datos.
Para desactivar la grabacion del showplan.out tenes que ponerle como valor a
la entrada JETSHOWPLAN OFF.
Espero que te sirva.
MAS
===
Otra cosa a riesgo de que alguno me lleve la contraria.... procura no
encadenar consultas con inner join, sobre todo si las tablas son grandes,
puedes sustituir dichos inner join por where
Esto es debido al momento en que realiza el filtro el where y el inner join,
pero en cualquier caso con una base de datos correctamente hecha (y no por
mi sino no lo afirmaría tan a ciencia cierta) una consulta de prueba
realizada con inner join (fueron 5) y otra consulta con where ordenadoas las
condiciones adecuadamente el tiempo disminuyo a casi la tercera parte.
Prueba realizada sobre una máquina servidor (ftp, telnet...) con varios
usuarios (no sé el número de personas que estarían en los diversos
laboratorios) y base de datos Oracle
(
geocities.com/es/ensolva/Descargas) (
geocities.com/es/ensolva) (
geocities.com/es)