TL;DR:Strings são provavelmente as mais seguras escolha, e a diferença de desempenho deve ser insignificante. Os números inteiros fazem sentido para coleções enormes em que o enum deve ser indexado. YMMV.

Verdadeiro.

Este é um benefício chave de números inteiros na minha opinião. No entanto, também exige que você verifique se os valores associados do enum não mude. Se você estragar tudo, você quase certamente causará estragos , o que é uma grande desvantagem.

Se você estiver realmente usando um tipo de dados enum, provavelmente é algum tipo de inteiro internamente, portanto, o inteiro deve exigir menos processamento. De qualquer forma, essa sobrecarga deve ser insignificante.

Estou repetindo muito do que foi dito, mas talvez isso ajude outros leitores. Resumindo:

• Misturar o mapa de valores enum causa estragos. Imagine seu Declined estados são subitamente interpretados como Accepted , porque Declined tinha o valor '2' e agora é Accepted porque você reordenou a enumeração e esqueceu de atribuir valores manualmente... (estremece )
• Strings são mais expressivas
• Inteiros ocupam menos espaço. O espaço em disco geralmente não importa, mas o espaço de índice consumirá RAM, o que é caro.
• As atualizações de números inteiros não redimensionam o objeto. Strings, se seus comprimentos variam muito, podem exigir uma realocação. O preenchimento de string e o fator de preenchimento devem aliviar isso.
• Inteiros podem ser sinalizadores (ainda não podem ser consultados (ainda), infelizmente, veja SERVER-3518 )
• Inteiros podem ser consultados por $gt / $lt para que você possa implementar com eficiência $or complexos consultas, embora isso seja um requisito bastante misterioso e não há nada de errado com $or consultas...