Leistungsnachteil bei Verwendung von Slug als Primärschlüssel/_id in Mongo?

Meiner Meinung nach nein. Der Leistungsunterschied ist für die meisten Szenarien vernachlässigbar (außer Paging ), aber

• Die alte Diskussion über Ersatz-Primärschlüssel kommt wieder hoch. Eine "Schnecke" ist kein sehr natürlicher Schlüssel. Ja, es muss einzigartig sein, aber wie Sie bereits betont haben, sollte es nicht unmöglich sein, den Slug zu ändern. Das allein würde mich davon abhalten...
• Eine monotone _id haben key kann Ihnen eine Reihe von Kopfschmerzen ersparen, vor allem um teures Paging per skip zu vermeiden und take (verwenden Sie $lt /$gt auf der _id stattdessen).
• Es gibt eine Grenze für die maximale Indexlänge in mongodb von weniger als 1024 Bytes. Auch wenn es nicht schön ist, dürfen URLs viel länger . Wenn jemand einen längeren Slug eingegeben hat, wird er nicht gefunden, weil er stillschweigend aus dem Index gelöscht wird.
• Es ist eine gute Idee, eine konsistente Schnittstelle zu haben, d. h. denselben Typ von _id zu verwenden auf alle oder zumindest die meisten Ihrer Objekte. In meinem Code habe ich eine einzige Ausnahme, bei der ich einen speziellen Hash als ID verwende, weil sich der Wert nicht ändern kann, die Sammlung extrem hohe Schreibraten hat und groß ist.
• Nehmen wir an, Sie möchten den Artikel in Ihrer Verwaltungsoberfläche (nicht auf der öffentlichen Website) verlinken. Welchen Link würden Sie verwenden? Normalerweise die ID, aber jetzt sind die ID und der Slug gleichwertig. Jetzt wäre ein einfacher Fehler (wie das Zulassen eines leeren Slugs) schwer zu beheben, da der Benutzer nicht einmal mehr zur Verwaltungsoberfläche gehen konnte.
• Sie werden sich mit Zeichensatzproblemen befassen. Ich würde vorschlagen, den Slug nicht einmal zum Nachschlagen des Artikels zu verwenden, sondern den Hash des Slugs .

Im Wesentlichen würden Sie mit einem Schema wie

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