En el tema de base de datos existen una gran cantidad de tipos de datos los cuales podemos utilizar para estructurar, vaya, nuestra base de datos. Los más conocidos son sin duda el varchar, el integer, el tinyint, el float y el datetime, prácticamente los usaremos en todas nuestras tablas, sin embargo, no son los únicos. 🤔
Utilizar los tipos de datos correctos será un punto clave para el éxito o el fracaso de nuestros proyectos, y lo digo enserio. Cada tipo de dato fue pensado para almacenar un valor en concreto. Computacionalmente hablando no es lo mismo almacenar, obtener y procesar un string que un flotante.
Es por ello que en esta ocasión me gustaría que habláramos acerca del tipo de dato enum, el cual creo yo, lo usaremos más de lo que uno puede pensar.
Para este post trabajaremos con el gestor de base de datos MySQL, aunque por supuesto, los conocimientos podrás aplicarlos para cualquier otro gestor. Bien, no perdamos más tiempo y comencemos.
Enum
Comencemos con la pregunta obligada, ¿Qué es un enum? Verás, en base de datos el tipo de dato enum no es más que un string el cual toma su valor de una lista previamente definida. Al nosotros asignar el tipo enum a un campo, este, no podrá almacenar otro valor que no se encuentre dentro de la lista.
Con el tipo de dato enum seremos capaces de reducir el universo de posibles valores a almacenar. Esto convierte al tipo enum en una excelente opción siempre que conozcamos todos los posibles valores a almacenar y sepamos que esos valores no cambiarán en el tiempo, o bueno, no en un tiempo cercano. 😃
¿Aún no te queda claro? no te preocupes, veamos un ejemplo.
Imaginemos que tenemos la necesidad de almacenar cierta información de nuestros usuarios, por ejemplo: su nombre, biografía, username y sexo.
En primera instancia uno pudiera pensar que para estos campos podemos utilizar el tipo de dato varchar, sin embargo, si lo analizamos un poco, esto no suena a una muy buena idea para el campo de sexo, ¿Por qué? 😰 ¿Qué pasa si definimos una tabla como la siguiente?
CREATE TABLE usuarios(
nombre VARCHAR(50),
biografia VARCHAR(50),
username VARCHAR(50),
sexo VARCHAR(10)
);
El problema viene cuando intentamos almacenar un usuario, ¿Qué estándar seguiremos para el campo sexo? ¿Acaso almacenaremos los strings "mujer" y "hombre" o "masculino" y "femenino"? ¿o almacenaremos las letras "M" y "F" o "M" y "H"? y si usamos letras ¿"M" no pudiera confundirse con mujer o masculino? ¿Ya entendierón mi punto? 🤔 En este caso estamos creando un problema donde no debería haberlo, estamos complicando aún más el problema inicial, dejando la responsabilidad a quien inserte o actualice la información.
Imaginemos una tabla con miles de registros, en donde no se siguío un estándar, donde hay usuarios con valores, masculinos, femeninos, m´s h´s, f´s o cualquier otro string que al programador de turno se le haya ocurrido, un completo caos, que dejame decirte sí pasa en el mundo real.
Para evitar esto, los enums.
Como ya conocemos de antemano todas las posibles opciones que podrá almacenar el campo reemplazemos el tipo varchar por enum.
CREATE TABLE usuarios(
nombre VARCHAR(50),
biografia VARCHAR(50),
username VARCHAR(50),
sexo ENUM('masculino', 'femenino')
);
Para definir el tipo enum basta con colocar ENUM, después del nombre del campo, paréntesis y dentro de los paréntesis todas las posibles opciones.
Al nosotros hacer esto el campo únicamente podrá almacenar valores que se encuentre dentro de la lista definida.
Si intentamos un:
INSERT INTO usuarios VALUES ('Rafael', 'Programador en CF', 'Rafa', 'masculino');
No deberíamos tener ningún problema.
Sin embargo, si intentamos almacenar un valor que no esté dentro de la lista, por ejemplo indefinido.
INSERT INTO usuarios VALUES ('Cody', 'Mascota', 'Cody', 'indefinido');
Obtendremos el error Data truncated for column.
Con esto, indirectamente estamos protegiendo los datos de nuestras tablas. 😼
Algo importante a mencionar es que MySQL no es sensible a las mayúsculas y minúsculas. Puedo colocar FEMENINO, todo en mayúsculas y no tendré ningún tipo de error.
INSERT INTO usuarios VALUES ('Marines', 'Programadora en CF', 'Marines', 'FEMENINO');
Otra forma de definir un valor al campo enum es mediante un número entero.
INSERT INTO usuarios VALUES ('Eduardo', 'Programador en CF', 'eduardo', 1);
Esto se debe, principalmente ,ya que las opciones que colocamos en el enum se encuentran enumeradas.
En mi caso masculino al ser la primera opción, esta se encuentra en la posición número 1 y femenino en la posición número 2. Es por ello que es importante el orden en el que coloquemos las opciones. 😉
Si deseamos actualizar el campo, de igual forma, podremos asignar un valor mediante un string o mediante un número entero.
Obtención de información
Bien, ya hablamos de la definición de la tabla y la inserción en esta, pero, ¿Qué pasa con la obtención de los datos? pues bien, déjame decirte que allí los enums también brillan.
Obtengamos todos los usuarios de la table cuyo sexo sea femenino. Para ello tenemos 2 opciones, mediante un string o mediante un número entero.
SELECT * FROM usuarios WHERE sexo = 'femenino';
o
SELECT * FROM usuarios WHERE sexo = 2;
En ambos casos obtendremos el mismo resultado.
Si es posible intenta definir las opciones de forma ascendente o descendente con respecto a algo. 😅
Por ejemplo, si estás trabajando con una tabla carrito de compras y quiere definir un campo estado, donde sabes que sus posibles opciones serán: creado, pagado, completado y cancelado, intenta definir las opciones de forma ascendente conforme al tiempo. Si en tu regla de negocios primero se pasa por el estado creado, después al estado pagado y finalmente a completado o cancelado, pues bien, creo que ese sería un buen orden:
creado 1, pagado 2, completado: 3 y cancelado: 4
Conclusión
En conclusión, siempre que conozcamos todas las posibles opciones que podrá almacenar un capo, y estas opciones sean "pocas", quizás, 3, 5 o 10, es una excelente idea utilizar enums sobre varchars, ya que el tipo enum por sí solo establece una regla sobre el campo, si por otro lado, las opciones son muchas más y cambiarán constantemente en el tiempo, pues allí es mejor utilizar otro tipo de estrategias. ☕