tipo MySQL ENUM vs unir tablas

Question

Mi requisito

Una tabla necesita para mantener una columna estado.

Esta columna representa uno de los 5 estados.

diseño inicial

que pensé que sólo puede hacer que sea una columna de número entero y representar los estados usando un valor numérico.

• 0 = marcha
• 1 = ejecutan
• 2 = chocaron
• 3 = detuvieron
• 4 = detuvieron

Como yo no quiero que mi aplicación para mantener la mapeo de los enteros a su descripción de cadena, planeo colocarlos en una tabla de descripción de estado separada (dependiendo de una relación FK).

Luego descubrí que MySQL tiene un tipo ENUM que coincide exactamente con mis requisitos. Aparte de una dependencia directa en MySQL, ¿hay algún inconveniente con el uso del tipo ENUM?

Answer 1

• Cambiar el conjunto de valores en un ENUM requiere una ALTER TABLE que podría causar una reestructuración de mesa - una operación muy costosa (la reestructuración de mesa no sucede si sólo tiene que añadir un nuevo valor al final de la Definición ENUM, pero si elimina uno o cambia el orden, hace una reestructuración de la tabla). Mientras que Cambiar el conjunto de valores en una tabla de búsqueda es tan simple como INSERT o DELETE.

• No hay forma de asociar otros atributos con los valores en un ENUM, como cuáles se retiran y cuáles son aptos para colocarse en una lista desplegable en su interfaz de usuario. Sin embargo, una tabla de búsqueda puede incluir columnas adicionales para dichos atributos.

• Es muy difícil consultar un ENUM para obtener una lista de valores distintos, básicamente requiriendo que consulte la definición del tipo de datos de INFORMATION_SCHEMA, y analice la lista del BLOB devuelto. Puede probar SELECT DISTINCT status desde su tabla, pero eso solo obtiene valores de estado actualmente en uso, que pueden no ser todos los valores en ENUM. Sin embargo, si mantiene los valores en una tabla de búsqueda, que es fácil de consultar, clasificar, etc.

No soy un gran fan de ENUM, como se puede ver. :-)

Lo mismo se aplica a las restricciones CHECK que simplemente comparan una columna con un conjunto fijo de valores. Aunque MySQL no admite restricciones CHECK de todos modos.

Answer 2

Una tabla sería más fácil de internacionalizar. Pero también lo haría una clase fuera de la base de datos por completo. Los enum me parecen una solución en la búsqueda de un problema, o lo que usas cuando todo lo que sabes son bases de datos.

Answer 3

Aquí está el artículo sobre speed comparison of enum. Tal vez da algunas pistas. En mi humilde opinión debe estar limitado a un uso en una lista fija de cadenas ("Sí/No", "Niño/Adulto") que con un 99% de probabilidad no cambia en el futuro.

Answer 4

Las entradas en mysql son malas por las razones ya explicadas.
Puedo agregar el siguiente hecho: Enum no garantiza ningún tipo de validación en el lado del servidor. Si inserta una fila con un valor que no sale en la definición enum, obtendrá un valor NULL o agradable en la base de datos, dependiendo de la capacidad NULL de la declaración del campo enum.

Mi punto sobre tinyints:
- enumeraciones se limitan a 65.535 valores
- si usted no necesita más de 256 valores, tinyint ocupará menos espacio para cada fila, y su comportamiento es mucho más "predecible" .

Answer 5

Si tiene muchos datos en su base de datos (más datos, entonces tiene RAM) y sus valores ENUM NUNCA van a cambiar, yo elegiría ENUM, en lugar de la unión. Debería ser más rápido.
Piénselo, en el caso de unión, necesita un índice en su clave externa e índice en su clave principal en la otra tabla. Como dijo Riho, mira los puntos de referencia.