Stocker l'énumération MongoDB

TL; DR :Les chaînes sont probablement plus sûres choix, et la différence de performance devrait être négligeable. Les nombres entiers ont du sens pour les collections volumineuses où l'énumération doit être indexée. YMMV.

Vrai.

C'est un avantage clé des nombres entiers à mon avis. Cependant, cela nécessite également que vous vous assuriez que les valeurs associées du enum ne change pas. Si vous ratez ça, vous ferez presque certainement des ravages , ce qui est un énorme désavantage.

Si vous utilisez réellement un type de données enum, il s'agit probablement d'une sorte d'entier en interne, donc l'entier devrait nécessiter moins de traitement. Dans tous les cas, ces frais généraux devraient être négligeables.

Je répète beaucoup de ce qui a été dit, mais peut-être que cela aide d'autres lecteurs. En résumé :

• Confondre la carte des valeurs enum fait des ravages. Imaginez votre Declined les états sont soudainement interprétés comme Accepted , car Declined avait la valeur '2' et maintenant c'est Accepted parce que vous avez réorganisé l'énumération et oublié d'attribuer des valeurs manuellement... (frissons )
• Les chaînes sont plus expressives
• Les nombres entiers prennent moins d'espace. L'espace disque n'a généralement pas d'importance, mais l'espace d'index consommera de la RAM, ce qui coûte cher.
• Les mises à jour d'entiers ne redimensionnent pas l'objet. Les chaînes, si leurs longueurs varient considérablement, peuvent nécessiter une réallocation. Le rembourrage des chaînes et le facteur de rembourrage devraient toutefois atténuer ce problème.
• Les nombres entiers peuvent être des drapeaux (pas encore interrogeable (encore), malheureusement, voir SERVER-3518 )
• Les nombres entiers peuvent être interrogés par $gt / $lt afin que vous puissiez implémenter efficacement des $or complexes requêtes, bien que ce soit une exigence plutôt obscure et qu'il n'y ait rien de mal avec $or requêtes...