Para mí es como usar valores codificados en lugar de variables constantes en el código de la aplicación. Pero hay diferentes opiniones por ahí. Entonces realmente no puedo decidir con seguridad.¿Está usando mysql ENUM una mala solución arquitectónica?
P.S. Para el alcance de esta pregunta, supongamos que el rendimiento no es un problema.
Depende de lo que está tratando de lograr, realmente. Si el rendimiento, como dices, no es un problema, depende en gran medida de tu filosofía y de la capacidad de cambio inherente de los datos. Si está utilizando un ENUM para almacenar valores para los días de la semana, para ayudar a la legibilidad humana, y la "capacidad de consulta" de los datos, entonces es un uso perfectamente válido (y muy superior, en algunos casos, al uso de números u otros representaciones). Sin embargo, si lo está usando para almacenar cosas como la categoría en la que se encuentra un producto (para lo cual el conjunto de categorías disponibles podría cambiar fácilmente), entonces es una solución muy pobre.
Esto depende mucho de la situación real, pero el punto de los tipos de columnas en primer lugar es definir con precisión qué valores están permitidos y cuáles no. Si, en el dominio de su problema, el atributo que está considerando almacenar como un valor ENUM es fijo en el sentido de que no es posible tener otros valores, entonces ENUM es una gran opción. Un ejemplo de eso sería el género: ENUM('male', 'female') es genial, porque la posibilidad de que se agregue un tercer género sería muy baja.
Si está almacenando valores que es más probable que cambien, entonces podría considerar normalizar su modelo de datos a una relación muchos a uno.
Supongamos que luego tiene que traducir esto a otro idioma, o suponga que el negocio lo obliga a aceptar 'M' y 'F'. – MattK
@MattK esos son problemas de aplicación/interfaz, no preocupaciones de datos. – molf
Veo lo que dice, pero ENUM ya está mezclando la interfaz con los datos. Si queríamos estos datos puros, simplemente use 0 y 1, entonces. Si desea que su BD tenga algo más legible (como 'masculino' y 'femenino'), ¿qué pasa si hay una necesidad futura de cambiar los datos (como la internacionalización)? – MattK
¡De ninguna manera! Tienen varias ventajas sobre un campo numérico:
De hecho, el uso de valores numéricos en lugar de las enumeraciones es como poner constantes en el código fuente.
ENUM es ideal para los datos que usted sabe que se incluirán en un conjunto estático.
Si está utilizando Mysql 5+, almacenamiento is almost always better con un tipo ENUM para datos en un conjunto estático, como muestra la referencia oficial de MySQL. Sin mencionar que los datos son legibles, y tienes una capa adicional de validación.
Si quiere saber si usar ENUM será una optimización, recomiendo usar PROCEDURE ANALYZE. Esto recomendará el tipo de datos adecuado para sus columnas.
El inconveniente práctico es la extensibilidad. No puede agregar un valor a la lista sin actualizar toda la tabla. No puede marcar valores para que sean históricos. La lista de valores es limitada. Aunque puede obtener lo mejor de ambos cuando mueve la función de lista al modelo MVC de su aplicación y deja que el tipo de columna sea CHAR. A menos que el rendimiento y el almacenamiento sean clave para su aplicación, no recomendaría el uso de enumeraciones cuando las aplicaciones solo utilizan la base de datos. – Code4R7