Cuando de bases de datos relacionales se habla, es indiscutible que uno de los RDBMS (Relational Database Management System) líderes es MySQL. Fue tan importante en la historia de la tecnología que hasta el día de hoy permanece como un estándar. Alojó los datos de Facebook en sus inicios, y a día de hoy sirve de modelo para aplicaciones web mundialmente famosas, como Joomla, Wordpress o Drupal.
Sin embargo, esconde dentro de sí una variedad enorme para construir el corazón de cualquier aplicación: el esquema. Acompañame a ver como podemos diseñar con una exactitud quirúrgica la implementación de nuestras entidades y relaciones, utilizando los dos potentes motores que ofrece MySQL en su core: <ins>InnoDB</ins> y <ins>MyISAM</ins>
El diseño, el gran cuello de botella
Antes de comenzar cualquier tutorial sobre bases de datos vale la pena recordar algunos conceptos básicos del diseño de las mismas, el cual es tan importante que dependiendo de su calidad puede dejar a una empresa en la bancarrota o convertirla en una startup.
Supongamos que vamos a construir un blog sobre autos deportivos 🚗🏁. Vamos a tener usuarios que publican posts, cada uno perteneciente a una categoría y con una o muchas etiquetas. Además, pueden escribir comentarios en cada artículo. Cada cosa remarcada en negrita es lo que llamamos entidad, la cual posee atributos que la caracterizan y relaciones con algunas otras.
En MySQL nosotros llamamos a las entidades tablas y a las bases de datos que alojan a estas entidades esquemas. Las tablas a veces reciben muchos registros en un tiempo corto, pero también muchas consultas en segundos. Por ejemplo, todas las semanas se registran nuevos usuarios, pero cada día se leen más de 10000 veces los posts del sitio. Y aquí está el quid de la cuestión…
Los desconocidos, InnoDB y MyISAM
Resulta que dentro de un Sistema Gestor de Bases de Datos existen también motores internos que se encargan de manejar, almacenar y recuperar información de las tablas que ya mencionamos. Se denominan storage-engine o motores de almacenamiento.
Lo importante es lograr encontrar el funcionamiento predominante de una tabla en nuestro sistema. ¿Vamos a escribir datos muy seguido? ¿Necesitamos hacer consultas constantemente? ¿Es importante cumplir con ACID (Atomicidad, Consistencia, Aislamiento y Durabilidad)?
Todas estas preguntas deben ser respondidas antes de crear la estructura de cada entidad. Una vez que lo hayamos hecho, es hora de escoger el engine correcto para construir nuestras tablas:
InnoDB, el rey de la escritura
Es un motor diseñado exclusivamente para fortalecer la Atomicidad, Consistencia, Aislamiento y Durabilidad en una base de datos. ¿Queremos hacer una gran cantidad de Transacciones? InnoDB. ¿Queremos una integridad formidable en nuestros datos? InnoDB. Y lo más importante, ¿Vamos a hacer un fuerte uso de las sentencias INSERT y UPDATE? Definitivamente InnoDB.
Un caso ideal para este storage-engine sería nuestra tabla de usuarios, cuya sentencia SQL de creación podría ser algo parecido a esto:
CREATETABLEIFNOTEXISTS`users` (
idINTUNSIGNED PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(100) NOTNULL,
passwordVARCHAR(64) NOTNULL,
email VARCHAR(150) NOTNULLUNIQUE,
active TINYINT NOTNULLDEFAULT1,
) ENGINE=InnoDB;
MyISAM, el rey de la lectura
Si estamos hablando de velocidad para hacer consultas, el claro ganador es MyISAM. Siendo optimistas (y buenos copywriters) nuestro blog recibirá miles y miles de vistas todos los días por fanáticos del automovilismo de todo el mundo. Sería un desastre que todo nuestro esquema de datos tardara más de lo esperado en responder a nuestro backend. Muchos usuarios se irían, y no queremos eso. Por ende, como van a producirse múltiples sentencias SELECT, MyISAM debe formar parte del core de nuestra tabla.
Una vez más, un nominado excelente para un ejemplo es la tabla de posts:
CREATETABLEIFNOTEXISTS`posts` (
idINTUNSIGNED PRIMARY KEY AUTO_INCREMENT,
title VARCHAR(150) NOTNULL,
contentTEXTNOTNULL,
author_id INTNOTNULL,
category_id INTNOTNULL,
Al ser el motor por defecto, no debemos aclararlo en la sentencia.
Conclusión
A partir de ahora sería un verdadero pecado como arquitectos de software o administradores de bases de datos no pensar en esta característica, que como dije en un principio puede a futuro determinar el éxito o fracaso de un proyecto. ¿Tienes alguna idea en mente que involucre datos que quieras hacer realidad? ¿Ya decidiste el storage-engine ideal para cada tabla? Házmelo saber en los comentarios, y no te pierdas el curso de SQL y MySQL de Platzi para profundizar en el tema y convertirte en un verdadero experto 😉
