Tipo de usar para las columnas "Estado" en una tabla de SQL

Question

Tengo un (ficticio) estructura de la tabla de la siguiente manera:

 
ticket 
    id: int(11) PK 
    name: varchar(255) 
    status: ????????? 

La pregunta es, ¿qué tipo de datos debo utilizar para el estado? Aquí están mis opciones, como los veo:

1. varchar que representa el estado - BAD porque no hay integridad
2. enumeración que representa el estado - BAD porque para cambiar el valor, que tendría que modificar la tabla, y entonces cualquier código con menús desplegables para los valores, etc, etc, etc
3. int FK a una tabla de estado - bueno porque es dinámico, BAD porque es más difícil de inspeccionar a simple vista (que puede ser útil) FK
4. varchar a un estado de table - BUENO porque es dinámico y visible en la inspección. MALO porque las claves son significativas, lo que generalmente es desaprobado. Curiosamente, en este caso es completamente posible que la tabla de estado tenga solo 1 columna, lo que la convierte en una enumeración glorificada

¿Tengo una lectura precisa de la situación? ¿Tener una clave significativa realmente es tan malo? Porque si bien me da piel de gallina, no tengo ninguna razón para ello hacerlo ...

Actualización: Para la opción 4, la estructura propuesta habría estado : char (4) FK, a una tabla de estado. Así,

OPEN => "Abrir"

CLOS => "Cerrado"

"esperar" => "Autorización pendiente"

"PROG" => "En curso

¿Cuál es la desventaja en este caso? el único beneficio que puedo ver de utilizar int sobre carbón en este caso es ligero rendimiento.

Answer 1

Vaya con el número 3. Cree una vista que se una en el valor de estado si desea algo inspeccionable.

Answer 2

te recomiendo que te vas con un campo StatusID lugar, una nd tiene una tabla separada mapeando la ID a un varchar?

EDIT: Supongo que eso es exactamente lo que delineaste en el punto 3. Creo que es la mejor opción.

Answer 3

Usaría una INT, y crearía una relación de clave externa con la tabla de estado. Un INT definitivamente debería ser seguro para una columna de estado enumerado.

Answer 4

Iría con el número 4, pero usaría una columna char(x). Si le preocupa el rendimiento, un char (4) ocupa tanto espacio (y, o al menos eso se podría pensar, un disco de E/S, ancho de banda y tiempo de procesamiento) como un int, que también requiere 4 bytes para almacenar. Si realmente te preocupa el rendimiento, conviértelo en un char (2) o incluso char (1).

No lo considere como "datos significativos", considérelo como una abreviatura de la clave natural. Sí, los datos tienen significado, pero como habrás notado que puede ser algo bueno cuando trabajas con los datos, significa que no siempre tienes que unirte (aunque sea a una tabla trivialmente pequeña) para extraer significado del base de datos.Y, por supuesto, la restricción de clave externa garantiza que los datos sean válidos, ya que deben estar en la tabla de búsqueda. (Esto también se puede hacer con restricciones CHECK, pero las tablas de búsqueda son generalmente más fáciles de administrar y mantener con el tiempo).

Lo malo es que puede quedar atrapado tratando de encontrar un significado. char (1) tiene un fuerte atractivo, pero si obtienes diez o más valores, puede ser difícil encontrar buenos valores significativos. Menos problema con char (4), pero sigue siendo un problema posible. Otro inconveniente: si es probable que los datos cambien, entonces sí, sus datos significativos ("PEND" = "Autorización pendiente") pueden perder su significado ("PEND" = "Reenviar a la oficina central para su aprobación inicial"). Ese es un mal ejemplo; Si los códigos de ese tipo cambian, es probable que sea mucho mejor refacturar su sistema para reflejar el cambio en las reglas comerciales. Supongo que mi punto debería ser, si es un valor de búsqueda ingresado por el usuario, las claves sustitutas (enteros) serán tus amigos, pero si están definidas y mantenidas internamente, definitivamente debes considerar valores más amigables para los humanos. Eso, o necesitarás notas post-em en tu monitor para recordarte qué diablos se supone que significa el estado = 31. (Tengo tres en el mío, y el stickum se desgasta cada pocos meses. Hable sobre el costo para mantener ...)

Answer 5

Supongo que su base de datos tiene un front end de alguna descripción, y que los usuarios regulares no están expuestos al código de estado.

Por lo tanto, su conveniencia es solo para programadores y DBA, personas importantes, pero no optimizaría mi diseño para ellos.

fuerte - Me gustaría tener mucho cuidado de usar abreviaturas "significativas" - los datos más flagrantes lío que he visto que ocurrió cuando un desarrollador fue la limpieza de algunos datos, y se interpreta la tecla "significativa" de forma incorrecta; resulta que "PROG" no significa "programado", sino "en progreso".

ir con la opción 3.

Answer 6

Creación de una tabla separada con el estado es una buena idea cuando se quiere mostrar la lista de la situación en el formulario HTML. Puede mostrar la descripción detallada de la tabla de búsqueda y ayudará al usuario a elegir el estado si los requisitos son así.

Desde la perspectiva del desarrollo, me gustaría ir entero como clave principal. Puede optimizarlo usando un entero pequeño/pequeño si sabe que no excederá el límite.

Si usa abreviatura como clave externa, debe pensar siempre en hacerlo único todo el tiempo, ya que @Philip Kelley lo mencionó como una desventaja.

Por último, puede declarar el tipo de tabla MYISAM si lo desea.

Actualización: Reflejando la opinión de @Philip Kelley, si hay demasiados estados, entonces es mejor usar un entero como clave externa. Si solo hay un par de estados, entonces se puede usar abbr como clave externa.