Seleccionar el tipo de dato apropiado
Una vez identificadas todas las tablas y columnas que necesita la base de datos, debemos determinar el tipo de dato de cada campo. Existen tres categorías principales que pueden aplicarse prácticamente a cualquier aplicación de bases de datos:
* Texto
* Números
* Fecha y hora
Cada uno de éstos presenta sus propias variantes, por lo que la elección del tipo de dato correcto no sólo influye en el tipo de información que se puede almacenar en cada campo, sino que afecta al rendimiento global de la base de datos.
A continuación se dan algunos consejos que nos ayudarán a elegir un tipo de dato adecuado para nuestras tablas:
* Identificar si una columna debe ser de tipo texto, numérico o de
fecha.
Esto suele ser un paso demasiado sencillo. Valores eminentemente
numéricos como códigos postales o cantidades monetarias deben
tratarse como campos de texto si decidimos incluir sus signos de
puntuación, pero obtendremos mejores resultados si los almacenamos
como números y solucionamos la cuestión del formato de alguna otra
forma.
* Elegir el subtipo más apropiado para cada columna.
Los campos de longitud fija (como CHAR) son generalmente más
rápidos que los de longitud variable (como VARCHAR), aunque ocupan
más espacio en disco.
El tamaño de cada campo debe restringirse al mínimo en función de
cuál pudiera ser la entrada más grande. Por ejemplo, si el valor
en una columna de tipo entero es menor de mil, lo mejor es
configurar esta columna como un SMALLINT de tres dígitos sin signo
(lo que permite exactamente 999 valores distintos).
* Configurar la longitud máxima para las columnas de texto y
numéricas, así como otros atributos.
Puede que nosotros tengamos preferencias distintas, pero el factor
más importante es siempre ajustar al máximo la información de cada
campo en lugar de usar siempre tipos TEXT e INT genéricos (e
ineficientes).
Utilizar índices apropiadamente
Los índices son un sistema especial que utilizan las bases de datos para mejorar su rendimiento global. Al definir índices en las columnas de una tabla, se le indica a MySQL que preste atención especial a dichas columnas.
MySQL permite definir hasta 32 índices por cada tabla y cada índice puede incorporar hasta 16 columnas. Aunque un índice de varias columnas puede no resultar de utilidad obvia a primera vista, lo cierto es que resulta muy útil a la hora de realizar búsquedas frecuentes sobre un mismo conjunto de columnas.
Dado que los índices hacen que las consultas se ejecuten más rápido, podemos estar incitados a indexar todas las columnas de nuestras tablas. Sin embargo, lo que tenemos que saber es que el usar índices tiene un precio. Cada vez que hacemos un INSERT, UPDATE, REPLACE, o DELETE sobre una tabla, MySQL tiene que actualizar cualquier índice en la tabla para reflejar los cambios en los datos.
¿Así que, cómo decidimos usar índices o no?. La respuesta es "depende". De manera simple, depende que tipo de consultas ejecutamos y que tan frecuentemente lo hacemos, aunque realmente depende de muchas otras cosas.
La razón para tener un índice en una columna es para permitirle a MySQL que ejecute las búsquedas tan rápido como sea posible (y evitar los escaneos completos de tablas). Podemos pensar que un índice contiene una entrada por cada valor único en la columna. En el índice, MySQL debe contar cualquier valor duplicado. Estos valores duplicados decrementan la eficiencia y la utilidad del índice.
Así que antes de indexar una columna, debemos considerar que porcentaje de entradas en la tabla son duplicadas. Si el porcentaje es demasiado alto, seguramente no veremos alguna mejora con el uso de un índice.
Otra cosa a considerar es qué tan frecuentemente los índices serán usados. MySQL puede usar un índice para una columna en particular si dicha columna aparece en la cláusula WHERE en una consulta. Si muy rara vez usamos una columna en una cláusula WHERE, seguramente no tiene mucha sentido indexar dicha columna. De esta manera, probablemente sea más eficiente sufrir el escaneo completo de la tabla las raras ocasiones en que se use esta columna en una consulta, que estar actualizando el índice cada vez que cambien los datos de la tabla.
Ante la duda, no tenemos otra alternativa que probar. Siempre podemos ejecutar algunas pruebas sobre los datos de nuestras tablas con y sin índices para ver como obtenemos los resultados más rápidamente. Lo único a considerar es que las pruebas sean lo más realistas posibles.
Usar consultas REPLACE
Existen ocasiones en las que deseamos insertar un registro a menos de que éste ya se encuentre en la tabla. Si el registro ya existe, lo que quisiéramos hacer es una actualización de los datos. En lugar de escribir el código que cumpla con esta lógica, y tener que ejecutar varias consultas, lo mejor es usar la sentencia REPLACE de MySQL.
Usar tablas temporales
Cuando estamos trabajando con tablas muy grandes, suele suceder que ocasionalmente necesitemos ejecutar algunas consultas sobre un pequeño subconjunto de una gran cantidad de datos. En vez de ejecutar estas consultas sobre la tabla completa y hacer que MySQL encuentre cada vez los pocos registros que necesitamos, puede ser mucho más rápido seleccionar dichos registros en una tabla temporal y entonces ejecutar nuestras consultas sobre esta tabla.
Crear una tabla temporal es tan sencillo como agregar la palabra TEMPORARY a una sentencia típica CREATE TABLE:
CREATE TEMPORARY TABLE tabla_temp
(
campo1 tipoDato,
campo2 tipoDeDato,
...
);
Una tabla temporal existe mientras dure la conexión a MySQL. Cuando se interrumpe la conexión MySQL remueve automáticamente la tabla y libera el espacio que ésta usaba. Nosotros podemos por supuesto eliminar esta tabla mientras estamos conectados a MySQL. Si una tabla nombrada tabla_temp ya existe en nuestra base de datos al momento de crear una tabla temporal con el mismo nombre, la tabla temporal oculta a la tabla no temporal.
MySQL también permite especificar que una tabla temporal sea creada en memoria si dicha tabla se declara del tipo HEAP:
CREATE TEMPORARY TABLE tabla_temp
(
campo1 tipoDato,
campo2 tipoDeDato,
...
) TYPE = HEAP;
Ya que las tablas del tipo HEAP son almacenadas en memoria, las consultas sobre estas tablas son ejecutadas mucho más rápido que en las tablas en disco no temporales. Sin embargo las tablas HEAP son ligeramente diferentes de una tabla normal y tienen algunas limitaciones propias.
Como en las sugerencias previas, lo único que nos queda es probar si con las tablas temporales nuestras consultas se ejecutan más rápidamente que usando la tabla que contiene una gran cantidad de datos. Si los datos están bien indexados puede que las tablas temporales no nos sean de mucha utilidad.
Usar una versión reciente de MySQL
La recomendación es simple y concreta, siempre que esté en nuestras manos, debemos usar la versión más reciente de MySQL que se encuentre disponible. Además de que las nuevas versiones frecuentemente incluyen muchas mejoras, cada vez son más estables y más rápidas. De esta manera, a la vez que sacamos provecho de las nuevas características incorporadas en MySQL, veremos significativos incrementos en la eficiencia de nuestro servidor de bases de datos.
Consideraciones finales
El último paso del diseño de la base de datos es adoptar determinadas convenciones de nombres. Aunque MySQL es muy flexible en cuanto a la forma de asignar nombre a las bases de datos, tablas y columnas, he aquí algunas reglas que es conveniente observar:
* Utilizar caracteres alfanuméricos.
* Limitar los nombres a menos de 64 caracteres (es una restricción
de MySQL).
* Utilizar el guión bajo (_) para separar palabras.
* Utilizar palabras en minúsculas (esto es más una preferencia
personal que una regla).
* Los nombres de las tablas deberían ir en plural y los nombres de
las columnas en singular (es igual una preferencia personal).
* Utilizar las letras ID en las columnas de clave primaria y foránea.
* En una tabla, colocar primero la clave primaria seguida de las
claves foráneas.
* Los nombres de los campos deben ser descriptivos de su contenido.
* Los nombres de los campos deben ser unívocos entre tablas,
excepción hecha de las claves.
Los puntos anteriores corresponden muchos de ellos a preferencias personales, más que a reglas que debamos de cumplir, y en consecuencia muchos de ellos pueden ser pasados por alto, sin embargo, lo más importante es que la nomenclatura utilizada en nuestras bases de datos sea coherente y consistente con el fin de minimizar la posibilidad de errores al momento de crear una aplicación de bases de datos.
Articulo Extraido de :
http://www.mysql-hispano.org/page.php?id=23
Autor: blueman