Prestatienadeel bij gebruik van slug als primaire sleutel/_id in mongo?

Volgens mij niet. Het prestatieverschil zal voor de meeste scenario's verwaarloosbaar zijn (behalve paging ), maar

• De oude discussie over surrogaat primaire sleutels komt naar voren. Een "slak" is geen erg natuurlijke sleutel. Ja, het moet uniek zijn, maar zoals je al aangaf, zou het veranderen van de slug niet onmogelijk moeten zijn. Dit alleen al zou ervoor zorgen dat ik me niet druk zou maken...
• Een monotone _id . hebben key kan u een aantal kopzorgen besparen, vooral om dure paging via skip . te vermijden en take (gebruik $lt /$gt op de _id in plaats daarvan).
• Er is een limiet op de maximale indexlengte in mongodb van minder dan 1024 bytes. Hoewel ze niet mooi zijn, mogen URL's veel langer . Als iemand een langere slug invoert, wordt deze niet gevonden omdat deze stilletjes uit de index wordt verwijderd.
• Het is een goed idee om een ​​consistente interface te hebben, d.w.z. hetzelfde type _id te gebruiken op alle, of in ieder geval, de meeste van uw objecten. In mijn code heb ik een enkele uitzondering waarbij ik een speciale hash als id gebruik omdat de waarde niet kan veranderen, de verzameling extreem hoge schrijfsnelheden heeft en groot is.
• Stel dat u naar het artikel in uw beheerinterface (niet naar de openbare site) wilt linken, welke link zou u dan gebruiken? Normaal gesproken zijn de id, maar nu zijn de id en de slug equivalent. Nu zou een simpele bug (zoals het toestaan ​​van een lege slug) moeilijk te herstellen zijn, omdat de gebruiker niet eens meer naar de beheerinterface kon gaan.
• Je krijgt te maken met problemen met tekensets. Ik stel voor om de slug niet eens te gebruiken om het artikel op te zoeken, maar de hash van de slug .

In wezen zou je eindigen met een schema als

{ "_id" : ObjectId("a237b45..."), // PK
  "slug" : "mongodb-is-fun", // not indexed
  "hash" : "5af87c62da34" } // indexed, unique