Rapidez, Indices y Consultas

[LinoVM]

Hola amigos, hace tiempo que me hago una pregunta.
Al trabajar con access y Definir por ejemplo;
Un campo Clave - RUT por ejemplo. y
Un Campo Indice - Nombre por ejemplo.

Tengo entendido que al generar una Clave se genera un indice en forma automática, por lo tanto la tabla tendría 2 índices (RUT y nombre). Cada uno de los índices tiene un nombre asignado por access (primary, secun ...) o por el usuario.

Al hacer la siguente consulta
Select * from Tabla where rut>'RutIngresado' order by nombre
o
Select * from Tabla where Nombre>'NombreIngresado' order by nombre
¿La velocidad de la consulta es la misma?
¿Debo indicar en que indice buscar?
¿Como se agrega un indice a la consulta?
¿El motor de base de datos o access lo hace automáticamente?

Espero su opinión.
Chaoooo...
Lino

[Mickel]

A menor cantidad de bits usados, mayor es la performance. Si ambos campos tienen indices, entonces la consulta sobre el campo con menor longitud es mas rapida.

Por lo tanto, si rut es un campo varchar(8) y nombre es un varchar(20), la consulta con rut sera mas rapida

[rafapaskual]

Hola, un tema interesante este. Creo recordar haber leido que en Acces cuanto menos indices tengas mas rápido va... alguien me puede decir si lo entendí mal, si es cierto, o que pasa? la verdad es que me extraña muchisimo!

Saludos!

[jachguate]

Acces cuanto menos indices tengas mas rápido va...

Esto es una verdad a medias. Cualquier motor de base de datos hará mas rápido las inserciones cuanto menos indices tenga. Es lógico, ya que cada vez que se inserta un registro a una tabla, hay que insertar su llave correspondiente en cada indice asociado a esta.

A la hora de los selects, no importa en realidad que una tabla tenga 1 o 30 indices. Lo que importa es que el motor pueda generar un plan de ejecución basado en indices. Es decir, si la condición del where es algo como

where edad > 20

Si hay un indice por la edad, la consulta irá que vuela, independientemente de si es el único indice que hay en la tabla o hay 20 mas... estos no importan.

Por el contrario, si no hay un indice sobre este campo... entonces el motor se verá obligado a hacer lo que en oracle se llama un "full table scan" para discriminar uno a uno los registros que cumplen la condición.

Entre mas complejas sean las clausulas where, asi como los joins, mas dificil será para el motor determinar el plan de ejecución óptimo. Lo recomendable es tener indices para todas las llaves foraneas, de manera que los joins sean eficientes. Luego, tener indices por los campos que se involucren directamente en los where. Los resultados variaran de un motor a otro, y Access, ciertamente, no se destaca por su capacidad de elaborar planes de ejecución óptimos..

Hasta luego.

;)

[rafapaskual]

Gracias por la explicación tio! un lujo!