Tcnicas de Optimizacin

Para qu se afina un sistema de base de datos? Puntos a tomar: los beneficios econmicos para una empresa y el beneficio humano. Beneficios econmicos para la Empresa: Evita gastar en costos adicionales de equipo. Se obtiene un mejor rendimiento. Al disminuir el equipo utilizado se disminuyen tambin los costos de mantenimiento tanto de software como hardware.

Beneficios Humanos: Incrementa la productividad, a la vez que satisface a los clientes de la organizacin

Quin es el encargado de afinar? El diseador debe dejar constancia del diseo del sistema, para que cualquier persona pueda entender el flujo de datos en una aplicacin. Los desarrolladores de aplicacin deben comunicar las estrategias de implementacin que escogen y aquellos mdulos y sentencias SQL que pueden ser rpida y fcilmente identificadas durante la tarea de afinamiento. El administrador de la base de datos debe monitorear y documentar las actividades del sistema cuidadosamente y aquellos rendimientos inusuales del sistema que pueden ser identificados y corregidos. Los administradores de hardware y software deben documentar y comunicar las configuraciones del hardware y software del sistema para que cualquiera pueda disear y administrar sistemas efectivamente.

AFINAMIENTO DE SQL

Cuando varios programadores estn desarrollando una aplicacin, cada uno tiene su propio estilo, preferencias y tendencias, aun cuando cada uno est produciendo un cdigo eficaz, su futuro mantenimiento puede darle un verdadero dolor de cabeza. A menudo cuando no se aplican normas en la codificacin significa que solo la persona que escribi el cdigo lo puede entender. Antes de iniciar a codificar una aplicacin es importante definir un estndar de programacin.

Uso de alias:

El uso de alias en las tablas y la inclusin de prefijos en todos los nombres de columnas cuando ms de una tabla es consultada, reducir el tiempo de anlisis de sintaxis y previene errores. Ejemplo: SELECT E.emp_no, name, tax_no, c.comp_code, comp_name FROM company C, Emp E WHERE E.comp_code = C.Comp_Code

Es mejor utilizar los Alias como se muestra a continuacin: SELECT E.emp_no, E.name, E.tax_no, C.Comp_Code, C.Comp_name FROM Company C, Emp E WHERE E.comp_code = C.comp_code

Utilizar bind variables:

Se aprovecha mejor el shared area si se utilizan bind variables. Ya que no es lo mismo: (Non-Sharable SQL) SELECT * FROM emp WHERE emp_no = 123; SELECT * FROM emp WHERE emp_no = 987;

(Sharable SQL) SELECT * FROM emp WHERE emp_no = :B1; (Bind value:123) SELECT * FROM emp WHERE emp_no = :B1; (Binde value:987);

Uso eficiente de la clusula WHERE:

SELECT ........ FROM emp E WHERE emp_salary > 50000 AND emp_type = MANAGER AND 25 < ( SELECT COUNT(*) FROM emp WHERE emp_mgr = E.emp_no)

Es mejor:
SELECT ........ FROM emp E WHERE 25 < ( SELECT COUNT(*)FROM emp WHERE emp_mgr = E.emp_no) AND emp_salary > 50000 AND emp_type = MANAGER

Usando ANDs sin competencia de ndices:

SELECT ........ FROM emp E WHERE 25 < ( SELECT COUNT(*)FROM emp WHERE emp_mgr = E.emp_no) OR (emp_salary > 50000 AND emp_type = MANAGER)

Es mejor:
SELECT ........ FROM emp E WHERE (emp_salary > 50000 AND emp_type = MANAGER) OR 25 < ( SELECT COUNT(*) FROM emp WHERE emp_mgr = E.emp_no)

Joins en lugar de EXISTS. EXISTS en lugar de JOINS. EXISTS en lugar de DISTINCT. NO EXISTS en lugar de NOT IN. IN o UNION en lugar de OR

La consulta SQL se vuelve ms rpida si se utiliza los nombres de las columnas

reales en la instruccin SELECT en lugar de '*'. En lugar de: SELECT * FROM estudiante; Es mejor: SELECT carnet, nombre, edad, sexo FROM estudiante;

HAVING es un filtro que se usa despus de agrupar o filtrar antes un conjunto de

registros. No se debe utilizar esta clusula para ningn otro propsito innecesario, si se pueden filtrar antes mejor.

Es mejor: SELECT carnet, COUNT(materias) FROM cursos WHERE material=fisica AND material=biologia GROUP BY carnet;

Que: SELECT carnet, COUNT(materias) FROM cursos GROUP BY carnet HAVING material=fisica AND material=biologia;

Minimizar el nmero de subconsultas, dando ms prioridad y tomando ms tiempo

en buscar la consulta principal.

Para chequeos, siempre es mejor crear restricciones (constraints) que disparadores

(triggers). Hay que optimizar dos tipos de instrucciones: las que consumen mucho tiempo en

ejecutarse, o aquellas que no consumen mucho tiempo, pero que son ejecutadas muchas veces.

Los filtros de las consultas deben ser lo ms especficos y concretos posibles. Es

decir: es mucho ms especfico poner WHERE campo = 'a' que WHERE campo LIKE '%a%'. Es muy recomendable utilizar siempre consultas que filtren por la clave primaria u otros campos indexados.

Las consultas ms utilizadas deben encapsularse en procedimientos almacenados.

Esto es debido a que el procedimiento almacenado se compila y analiza una sola vez, mientras que una consulta (o bloque PL/SQL) lanzado a la base de datos debe ser analizado, optimizado y compilado cada vez que se lanza.

Cuando se hace una consulta multi-tabla con joins, el orden en que se ponen las

tablas en el FROM influye en el plan de ejecucin. Aquellas tablas que retornan ms filas deben ir en las primeras posiciones, mientras que las tablas con pocas filas deben situarse al final de la lista de tablas.

Siempre que sea posible se deben evitar las funciones de conversin de tipos de

datos e intentar hacer siempre comparaciones con campos del mismo tipo. Si hay que hacer algn tipo de conversin, evitar el uso del cast y aplicar siempre la funcin de conversin sobre la constante, y no sobre la columna.