Pildoritas de Bases de Datos: Diseño de Bases de Datos II

En el anterior artículo de Pildoritas de Bases de Datos hablamos largo y tendido del Diseño de Bases de Datos, en concreto sobre la realización de un digrama Entidad / Relación y su posterior normalización.

Cuando un modelo de datos está normalizado hasta la tercera forma normal nuestro diseño ya es bastante bueno. Gracias a la normalización no deberías tener datos redundantes, ni columnas iguales con enumeraciones (proyecto 1, proyecto2…proyecto n), etc.

No obstante, hay otras consideraciones que debemos tener en cuenta y que paso a mencionar a continuación. Son algunas recomendaciones que creo os resultarán de ayuda si tenéis algún día que realizar el diseño de una BBDD.

No guardes datos innecesarios ni consultes campos que no requieras

Hay que grabarse a fuego una verdad que a veces obviamos: No hay nada más costoso en tiempo que el acceso a BBDD. Por tanto, siempre tenemos que evitar acceder a ella de forma “gratuita”.

Mucha gente piensa eso de que no hay nada malo en guardar todo lo posible en BBDD. De hecho, cuanto más guarde pues mejor, no vaya a ser que un futuro haya datos que no almacenaba y luego hagan falta.

Hay que tener presente que la BBDD consiste en pedir a un servicio (muchas veces en otra máquina) que lea de disco una información y nos la devuelva, así que cuanto mayor sea el tamaño de estas tablas, mayor tiempo nos llevará acceder a ellas.

Es por ello que aquellos datos que puedan calcularse a partir de otros no deben de estar almacenados en la bases de datos. Así mismo, si tenemos que recoger datos de BBDD, deberemos de recuperar los campos que sean necesarios, no hacer, por ejemplo, un SELECT * FROM tabla.

Selecciona el tipo de dato y longitud adecuados

Parece una tontería pero veo a mucha gente poco cuidadosa en este aspecto. Por ejemplo, a la hora de crear un campo de texto, mucha gente decide crear un campo VARCHAR por pura costumbre, cuando a lo mejor en un caso concreto los valores de un campo siempre van a tener una longitud fija y merece la pena mejor crearlo de tipo CHAR, ya que ocupa menos. Otro ejemplo es crear un campo de tipo DATETIME cuando lo que se necesita almacenar es sólo la fecha y valdría un campo DATE. En general, hay que pararse un segundo a ver de qué tipo de dato es cada atributo y con qué longitud debemos crear cada campo.

También hay que tener en cuenta la integridad de datos. En el ejemplo del anterior artículo el Nombre y Apellidos del empleado no deberían aceptar caracteres nulos, o el DNI, en caso de que no fuera una PK, debería de ser único. Podemos pensar que esa validación no tiene sentido si no vamos a recibir ese campo vacío nunca por imposición de la lógica de negocio, pero hay amigos, los caminos del desarrollo software son inescrutables, así que mejor poner control desde BBDD no vaya a ser que nos llevemos una sorpresita y a algún proceso le de por saltarse esta norma y meter a un pobre empleado sin nombre ni apellidos.

Crea índices cuando sea posible

Los índices funcionan un poco como el índice de los libros (así a groso modo y por no liar mucho) y sirven para agilizar el tiempo de ejecución de las consultas de SQL. Usando la analogía del libro, si queremos ir al Capítulo 5, en vez de ir página a página hasta que lleguemos a él, mejor mirar el índice e ir a la página directamente.

La primera pregunta que nos asalta a todos cuando oímos por primera vez hablar sobre ellos es “¿Por qué no ponemos índices en todas las columnas?

A parte de que guardar las relaciones de los índices y los datos de la columna ocupa espacio (a veces más que la propia tabla), tenemos que tener en cuenta que cada vez que insertemos, borremos o actualicemos en la BBDD, tendremos también que consumir tiempo en actualizar la relación del índice.

Por tanto, tener demasiados índices en el fondo acaba empeorando el tiempo de respuesta global del acceso a la base de datos, por lo que crearemos un índice cuando tengamos claro que es beneficioso.

¿Cómo sabemos que es beneficioso? Pues es difícil saberlo. Lo mejor con los índices siempre es realizar un explain plan antes y después de añadir el índice para ver si mejora la respuesta, pero intentaremos marcar unas pautas generales que nos ayudarán a la hora de crear índices eficientes.

Para empezar los índices deben encontrarse más como filtro de nuestras consultas (es decir, en el WHERE) que ser parte de los datos que obtenemos (los campos indicados tras el SELECT).

Tampoco es buena idea marcar como índice aquella columna que tiene muchos valores idénticos. Por ejemplo, una columna booleana que indica True o False no tendría sentido colocarla como índice. Por tanto, un índice debe ser un campo donde muchos de los valores sean distintos. Si la tabla tiene pocos registros tampoco merece la pena crear un índice, ya que no mejorará sustancialmente la el tiempo de respuesta.

Por último, hay que tener también en cuenta cuando se crea un índice la regla de la izquierda. Si filtramos por dos campos en el WHERE muy a menudo, más que indicar dos índices por cada campo deberíamos crear un índice multicolumna. A la hora de utilizar dicho índice multicolumna tenemos que tener en cuenta la regla de la izquierda que os comentaba: Hay que incluir en el WHERE las columnas indexadas por orden de izquierda a derecha al igual están definidas en el índice o si no, la consulta no usará dicho índice. Además, en los índices multicolumna si sólo hacemos referencia a uno de sus campos no usaremos el índice completo, por lo que hay que tener muy claro cuando definir un índice de este tipo en vez de uno simple. Hablaré sobre este tema de nuevo en la parte de optimización SQL.

Define una hoja de estilos y mantenla siempre

En algunos casos, como MySQL, hay diferenciación entre mayúsculas y minúsculas en el nombre de las tablas, es por ello que viene bien definir un estándar a la hora de ponerles un nombre: Todas en mayúscula o en formato camelCase. Tampoco es recomendable utilizar caracteres especiales a la hora de nombrar tablas o campos.

Si todos los campos se deciden nombrar en singular, esto tiene que ser así siempre. Por otra parte, si estas desarrollando una aplicación que puede ser utilizada por gente de otros países es recomendable usar siempre nombres en inglés.

Resumiendo, márcate tu propio estándar o usa uno ya existente, pero sigue ese estándar a muerte.

Las reglas que yo suelo usar, pero que pueden ser perfectamente otras, son las siguientes:

  • Separa las palabras a partir de un guión bajo o siguiendo el estilo camelCase. En mi caso prefiero la primera opción.
  • Nombra la tabla y los campos en singular.
  • Si tienes muchas tablas que pueden ser agrupadas en grupos lógicos, utiliza un prefijo que te ayude a identificarlas.
  • Intenta que los nombres sean descriptivos y evita abreviaciones, pero sin que sean demasiado largos.
  • Los campos Primary Key deben empezar por el prefijo ID.
  • Primero se crearán los campos PK, seguidos luego de las FK.
  • Escribir todo en mayúsculas o minúsculas. En mi caso soy más de la primera opción.
  • No utilizar caracteres numéricos, al menos en el nombre de las tablas.
  • Los campos que estén en varias tablas (como las FK) deben tener el mismo nombre.

Bueno, con este post ya acabamos la parte de Diseño de Bases de Datos. En la siguiente pildorita vamos a empezar ya un poco con la sintáxis SQL, ¡así que estaros atentos!

Índice de Pildoritas

Share