El lenguaje SQL es no procedimental, es decir, en las sentencias se indica que queremos conseguir y no como lo tiene que hacer el interprete para conseguirlo. Esto es pura teor�a, pues en la pr�ctica a todos los gestores de SQL hay que especificar sus propios truquitos para optimizar el rendimiento.
Por tanto, muchas veces no basta con especificar una sentencia SQL correcta, sino que adem�s, hay que indicarle como tiene que hacerlo si queremos que el tiempo de respuesta sea el m�nimo. En este apartado veremos como mejorar el tiempo de respuesta de nuestro interprete ante unas determinadas situaciones:
�Dise�o de las tablas
- Normaliza las tablas, al menos hasta la tercera forma normal, para asegurar que no hay duplicidad de datos y se aprovecha al m�ximo el almacenamiento en las tablas. Si hay que desnormalizar alguna tabla piensa en la ocupaci�n y en el rendimiento antes de proceder.
- Los primeros campos de cada tabla deben ser aquellos campos requeridos y dentro de los requeridos primero se definen los de longitud fija y despu�s los de longitud variable.
- Ajusta al m�ximo el tama�o de los campos para no desperdiciar espacio.
- Es muy habitual dejar un campo de texto para observaciones en las tablas. Si este campo se va a utilizar con poca frecuencia o si se ha definido con gran tama�o, por si acaso, es mejor crear una nueva tabla que contenga la clave primaria de la primera y el campo para observaciones.
�Gesti�n y elecci�n de los �ndices
Los �ndices son campos elegidos arbitrariamente por el constructor de la base de datos que permiten la b�squeda a partir de dicho campo a una velocidad notablemente superior. Sin embargo, esta ventaja se ve contrarrestada por el hecho de ocupar mucha m�s memoria (el doble m�s o menos) y de requerir para su inserci�n y actualizaci�n un tiempo de proceso superior.
Evidentemente, no podemos indexar todos los campos de una tabla extensa ya que doblamos el tama�o de la base de datos. Igualmente, tampoco sirve de mucho el indexar todos los campos en una tabla peque�a ya que las selecciones pueden efectuarse r�pidamente de todos modos.
Un caso en el que los �ndices pueden resultar muy �tiles es cuando realizamos peticiones simult�neas sobre varias tablas. En este caso, el proceso de selecci�n puede acelerarse sensiblemente si indexamos los campos que sirven de nexo entre las dos tablas.
Los �ndices pueden resultar contraproducentes si los introducimos sobre campos triviales a partir de los cuales no se realiza ning�n tipo de petici�n ya que, adem�s del problema de memoria ya mencionado, estamos ralentizando otras tareas de la base de datos como son la edici�n, inserci�n y borrado. Es por ello que vale la pena pensarselo dos veces antes de indexar un campo que no sirve de criterio para b�squedas o que es usado con muy poca frecuencia por razones de mantenimiento.
�Campos a Seleccionar
- En la medida de lo posible hay que evitar que las sentencias SQL est�n embebidas dentro del c�digo de la aplicaci�n. Es mucho m�s eficaz usar vistas o procedimientos almacenados por que el gestor los guarda compilados. Si se trata de una sentencia embebida el gestor debe compilarla antes de ejecutarla.
- Seleccionar exclusivamente aquellos que se necesiten
- No utilizar nunca SELECT * por que el gestor debe leer primero la estructura de la tabla antes de ejecutar la sentencia
- Si utilizas varias tablas en la consulta especifica siempre a que tabla pertenece cada campo, le ahorras al gestor el tiempo de localizar a que tabla pertenece el campo. En lugar de SELECT Nombre, Factura FROM Clientes, Facturacion WHERE IdCliente = IdClienteFacturado, usa: SELECT Clientes.Nombre, Facturacion.Factura WHERE Clientes.IdCliente = Facturacion.IdClienteFacturado.
�Campos de Filtro
- Se procurar� elegir en la cl�usula WHERE aquellos campos que formen parte de la clave del fichero por el cual interrogamos. Adem�s se especificar�n en el mismo orden en el que est�n definidos en la clave.
- Interrogar siempre por campos que sean clave.
- Si deseamos interrogar por campos pertenecientes a indices compuestos es mejor utilizar todos los campos de todos los indices. Supongamos que tenemos un �ndice formado por el campo NOMBRE y el campo APELLIDO y otro �ndice formado por el campo EDAD. La sentencia WHERE NOMBRE='Juan' AND APELLIDO Like '%' AND EDAD = 20 ser�a m�s optima que WHERE NOMBRE = 'Juan' AND EDAD = 20 por que el gestor, en este segundo caso, no puede usar el primer �ndice y ambas sentencias son equivalentes porque la condici�n APELLIDO Like '%' devolver�a todos los registros.
�Orden de las Tablas
- Cuando se utilizan varias tablas dentro de la consulta hay que tener cuidado con el orden empleado en la clausula FROM. Si deseamos saber cuantos alumnos se matricularon en el a�o 1996 y escribimos: FROM Alumnos, Matriculas WHERE Alumno.IdAlumno = Matriculas.IdAlumno AND Matriculas.A�o = 1996 el gestor recorrer� todos los alumnos para buscar sus matriculas y devolver las correspondientes. Si escribimos FROM Matriculas, Alumnos WHERE Matriculas.A�o = 1996 AND Matriculas.IdAlumno = Alumnos.IdAlumnos, el gestor filtra las matr�culas y despu�s selecciona los alumnos, de esta forma tiene que recorrer menos registros.