Winkel enum MongoDB

TL;DR:Strings zijn waarschijnlijk de veiliger keuze, en het prestatieverschil zou verwaarloosbaar moeten zijn. Gehele getallen zijn logisch voor enorme collecties waar de opsomming moet worden geïndexeerd. YMMV.

Waar.

Dit is naar mijn mening een belangrijk voordeel van gehele getallen. Het vereist echter ook dat u ervoor zorgt dat de bijbehorende waarden van de enum verander niet. Als je dat verknoeit, zul je vrijwel zeker grote schade aanrichten , wat een enorm nadeel is.

Als u daadwerkelijk een enum-gegevenstype gebruikt, is het intern waarschijnlijk een soort geheel getal, dus het gehele getal zou minder verwerking nodig hebben. Hoe dan ook, die overhead zou verwaarloosbaar moeten zijn.

Ik herhaal veel van wat er is gezegd, maar misschien helpt dat andere lezers. Samenvattend:

• Het door elkaar halen van de enum-waardekaart richt grote schade aan. Stel je voor dat je Declined statussen worden plotseling geïnterpreteerd als Accepted , omdat Declined had de waarde '2' en is nu Accepted omdat je de enum opnieuw hebt gerangschikt en bent vergeten handmatig waarden toe te kennen... (huivering )
• Snaren zijn expressiever
• Gehele getallen nemen minder ruimte in beslag. Schijfruimte doet er meestal niet toe, maar indexruimte verbruikt RAM, wat duur is.
• Integer-updates wijzigen de grootte van het object niet. Strings, als hun lengte sterk varieert, kan een hertoewijzing vereisen. String-opvulling en opvulfactor zouden dit echter moeten verlichten.
• Gehele getallen kunnen vlaggen zijn (nog niet opvraagbaar), zie SERVER-3518 )
• Gehele getallen kunnen worden opgevraagd door $gt / $lt zodat u complexe $or . efficiënt kunt implementeren vragen, hoewel dat een nogal mysterieuze vereiste is en er is niets mis met $or vragen...