Ydeevne ulempe ved at bruge slug som primær nøgle/_id i mongo?

Efter min mening nej. Ydeevneforskellen vil være ubetydelig for de fleste scenarier (undtagen personsøgning ), men

• Den gamle diskussion om primære surrogatnøgler dukker op. En "snegl" er ikke en særlig naturlig nøgle. Ja, det skal være unikt, men som du allerede har påpeget, burde det ikke være umuligt at skifte sneglen. Dette alene ville holde mig fra at genere...
• At have et monotont _id nøgle kan spare dig for en række hovedpine, vigtigst af alt for at undgå dyr personsøgning via skip og take (brug $lt /$gt på _id i stedet).
• Der er en grænse for maksimal indekslængde i mongodb på mindre end 1024 bytes. Selvom det ikke er smukt, må webadresser være meget længere . Hvis nogen indtastede en længere slug, ville den ikke blive fundet, fordi den stille er slettet fra indekset.
• Det er en god idé at have en ensartet grænseflade, dvs. at bruge den samme type _id på alle eller i det mindste de fleste af dine genstande. I min kode har jeg en enkelt undtagelse, hvor jeg bruger en speciel hash som id, fordi værdien ikke kan ændres, samlingen har ekstremt høje skrivehastigheder og den er stor.
• Lad os sige, at du vil linke til artiklen i din administrationsgrænseflade (ikke det offentlige websted), hvilket link vil du bruge? Normalt er id'et, men nu er id'et og sneglen ækvivalente. Nu ville en simpel fejl (såsom at tillade en tom snegl) være svær at komme sig fra, fordi brugeren ikke engang kunne gå til administrationsgrænsefladen længere.
• Du kommer til at beskæftige dig med problemer med tegnsæt. Jeg vil foreslå, at du ikke engang bruger sneglen til at slå artiklen op, men sneglens hash .

Grundlæggende ville du ende med et skema som

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