TL;DR:las cadenas son probablemente las más seguras elección, y la diferencia de rendimiento debe ser insignificante. Los enteros tienen sentido para grandes colecciones en las que se debe indexar la enumeración. YMMV.
Cierto.
En mi opinión, este es un beneficio clave de los números enteros. Sin embargo, también requiere que se asegure de que los valores asociados de enum no cambies Si lo arruinas, casi seguro causarás estragos. , lo cual es una gran desventaja.
Si en realidad está utilizando un tipo de datos de enumeración, probablemente sea algún tipo de número entero internamente, por lo que el número entero debería requerir menos procesamiento. De cualquier manera, esa sobrecarga debería ser insignificante.
Estoy repitiendo mucho de lo que se ha dicho, pero tal vez eso ayude a otros lectores. Resumiendo:
- Confundir el mapa de valores de enumeración causa estragos. Imagina tu
Declinedlos estados se interpretan repentinamente comoAccepted, porqueDeclinedtenía el valor '2' y ahora esAcceptedporque reordenó la enumeración y olvidó asignar valores manualmente... (estremecimientos ) - Las cadenas son más expresivas
- Los números enteros ocupan menos espacio. El espacio en disco no importa, por lo general, pero el espacio de índice consumirá RAM, lo cual es costoso.
- Las actualizaciones de enteros no cambian el tamaño del objeto. Las cadenas, si sus longitudes varían mucho, pueden requerir una reasignación. Sin embargo, el relleno de cadenas y el factor de relleno deberían aliviar esto.
- Los números enteros pueden ser indicadores (aún no consultables (todavía), desafortunadamente, consulte SERVER-3518 )
- Los enteros pueden ser consultados por
$gt/$ltpara que pueda implementar de manera eficiente$orcomplejos consultas, aunque ese es un requisito bastante arcano y no hay nada malo con$orconsultas...
