¿cómo guardas un enum en la DB?

[Kiquenet]

 Javier Mengual Betancourt :

 Hoy he perdido horas por culpa de un enum. Y lo peor es que el problema era doble. Primer problema: ¿cómo guardas un enum en la DB? Parece una tontería pero no hay respuesta obvia. Cada opción tiene su trampa: Guardarlo como int es lo más común y lo más rápido. Pero cuando abres la DB directamente ves 0, 1, 2... y sin el código delante no sabes qué significa cada valor. En equipos grandes o con reportes externos eso se convierte en un problema real. Guardarlo como string es legible y fácil de debuggear. Pero los índices ocupan más, las consultas son más lentas y si algún día renombras el enum sin migración te cargas los datos silenciosamente. Crear una tabla propia con FK es lo más robusto, tienes integridad referencial real y la DB es autodescriptiva. Pero es un join más en cada consulta y más complejidad para algo que en el código es simplemente un enum. No hay respuesta perfecta. Cada equipo elige su veneno según el contexto. Pero ese no era el problema gordo. Segundo problema: tenía el enum directamente en el DTO. public StorageType Storage { get; set; } Tenía FluentValidation. Tenía ProblemDetails. Todo perfecto sobre el papel. Hasta que llegó un request con un valor inválido. 500 genérico. FluentValidation ni se enteró. ¿Por qué? Porque ASP.NET deserializa el JSON ANTES de que llegues a la validación. Si el enum no matchea, lanza una excepción y tu código nunca se ejecuta. Fue entonces cuando leí esto en Reddit: "Do not ship your types to your client, only madness is waiting" Razón no le falta. Solución: string en el DTO, FluentValidation valida que sea un valor válido, el handler convierte a enum internamente. La API habla JSON puro, el dominio trabaja siempre tipado. Dos problemas distintos, misma raíz: exponer detalles internos donde no tocan. ¿Vosotros como lo hubierais hecho?

[Kiquenet]

Fernando Escolar:

Prefiero guardarlos como string, tanto en BBDD como en la API. Así evito un “código secreto”. Mejor un valor legible que sepas qué significa.

Entiendo que en sistemas críticos puedes usar valores numéricos, pero… usas c#?

JSON: JsonStringEnumConverter
EF: EnumToStringConverter

Y para la gestión de errores usaría otro método como un middleware que instrumente y formatee los errores.

No condicionaría el comportamiento de mi API (o DTO) porque no me guste como o cuando deserializa algo o el error que genera…


NetmentorTW
Number siempre en la BBDD. Mirar el valor son 10 segundos durante un incidente, y fuera de el los beneficios son mucho mayores. Ahora sí tú app recibe 10 llamada por minuto pues te da igual.

En API rest me gusta usar el string, porque rest esta pensado para que los humanos lo entiendan.

El error de la api de .net no es cierto del todo, falla y el error es genérico, pero genérico dentro se los enun diciendo que no es un valor válido, por cierto es un 400 con problem details, no un 500.
Finalmente, ese error de un enun no deberia pasar. Que han hecho programar el cliente a mano en vez de automáticamente usando la especificación openapi de referencia?