Bajo rendimiento de mysql y php

[robervcp]

Normalizar las estructuras de tablas

Si nunca antes hemos oído hablar de la "normalización de datos", no debemos temer. Mientras que la normalización puede parecer un tema complejo, nos podemos beneficiar ampliamente al entender los conceptos más elementales de la normalización.

Una de las formas más fáciles de entender esto es pensar en nuestras tablas como hojas de cálculo. Por ejemplo, si quisiéramos seguir la pista de nuestra colección de CDs en una hoja de cálculo, podríamos diseñar algo parecido a lo que se muestra en la siguiente tabla.

+------------+-------------+--------------+ .. +--------------+
| album | track1 | track2 | | track10 |
+------------+-------------+--------------+ .. +--------------+
| Antrologia | Tarzan Boy | Life is life | .. | Square rooms |
| | (Baltimora) | (Opus) | .. | (Al Corley) |
+------------+-------------+--------------+ .. +--------------+


Esto parece razonable. Sin embargo el problema es que el número de pistas que tiene un CD es bastante variable. Esto significa que con este método tendríamos que tener una hoja de cálculo realmente grande para albergar todos los datos, que en los peores casos podrían ser de hasta 20 pistas. Esto en definitiva no es nada bueno.

Uno de los objetivos de una estructura de tabla normalizada es minimizar el número de "celdas vacías". En el caso de la tabla de CDs que estamos tratando, tendríamos muchas de estas celdas si permitiéramos CDs de 20 pistas o más. En el caso de que las listas de campos pueden expandirse "hacia la derecha", como en este ejemplo de los CDs, nos da una pista de que necesitamos dividir los datos en dos o más tablas a las que luego podamos acceder de forma conjunta para obtener los datos que necesitemos.

Mucha gente nueva en los sistemas de bases de datos relacionales no sabe en verdad lo que significa "relacional" en RDBMS (/Relational Database Management System/). En términos simples, grupos parecidos de información son almacenados en distintas tablas que luego pueden ser "juntadas" (relacionadas) basándose en los datos que tengan en común. Desafortunadamente esto suena bastante académico y vago, sin embargo, en nuestra base de datos de CDs podemos ejemplificar una situación concreta en la que veremos cómo normalizar los datos.

El darnos cuenta de que cada lista de CDs tiene un conjunto fijo de atributos (título, artista, año, género) y un conjunto variable de atributos (el número de pistas) nos da una idea de cómo dividir los datos en múltiples tablas que luego podamos relacionar entre sí. Podemos crear una tabla que contenga una lista de todos los álbumes y sus atributos fijos y otra que contenga una lista de todas las pista de esos álbumes. De esta forma, en vez de pensar en forma horizontal (como con la hoja de cálculo), pensamos en forma vertical y dejamos una estructura de tablas como la que se muestra a continuación.

CREATE TABLE album (
id_album INTEGER NOT NULL AUTO_INCREMENT PRIMARY KEY,
titulo VARCHAR(80) NOT NULL );

CREATE TABLE pista (
id_album INTEGER NOT NULL,
numero INTEGER NOT NULL,
titulo VARCHAR(80) NOT NULL );


El identificador de álbum (id_album) es lo que relaciona las distintas pistas de un álbum dado. El campo id_album en la tabla pista coincide con el campo id_album en la tabla album, de tal manera que para obtener una lista de todas las pistas de un álbum dado, podríamos realizar una consulta como esta:

SELECT pista.numero, pista.nombre FROM album, pista WHERE album.titulo = "El titulo del album" AND album.id_album = pista.id_album


Esta estructura es a la vez flexible y eficiente. La flexibilidad está en el hecho que podemos agregar datos al sistema posteriormente sin tener que rescribir lo que ya tenemos. Por ejemplo, si quisiéramos agregar la información de los artistas de cada álbum, lo único que tenemos que hacer es crear una tabla artista que esté relacionada a la tabla album de la misma manera que la tabla pista. Por lo tanto, no tendremos que modificar la estructura de nuestras tablas actuales, simplemente agregar la que hace falta.

La eficiencia se refiere al hecho de que no tenemos duplicación de datos, y tampoco tenemos grandes cantidades de "celdas vacías". De esta manera MySQL no tiene que almacenar más datos de los necesarios, ni gastar recursos al revisar las áreas vacías en nuestras tablas.

El objetivo principal del diseño de bases de datos es generar tablas que modelan los registros en los que guardaremos nuestra información. Es importante que esta información se almacene sin redundancia para que se pueda tener una recuperación rápida y eficiente de los datos. A través de la normalización tratamos de evitar ciertos defectos que nos conduzcan a un mal diseño y que lleven a un procesamiento menos eficaz de los datos.

Podríamos decir que estos son los principales objetivos de la normalización:

* Controlar la redundancia de la información.
* Evitar pérdidas de información.
* Capacidad para representar toda la información.
* Mantener la consistencia de los datos.

Si somos novatos en el ambiente de las bases de datos relacionales pudiéramos pensar que con la normalización nuestros datos tienen una apariencia extraña, sin embargo, esto le permite a MySQL ser muy eficiente al momento de almacenar y recuperar los datos de las tablas, además de que nos da la flexibilidad de crecer y escalar nuestras aplicaciones sin la necesidad de reestructurar una base de datos a cada momento.