Недостатък на производителността при използване на slug като първичен ключ/_id в mongo?

Според мен не. Разликата в производителността ще бъде незначителна за повечето сценарии (с изключение на пейджинг ), но

• Появява се старата дискусия за сурогатните първични ключове. „Охлюв“ не е много естествен ключ. Да, трябва да е уникален, но както вече посочихте, промяната на плужека не трябва да е невъзможна. Само това би ме предпазило от безпокойство...
• Имат монотонен _id ключът може да ви спести редица главоболия, най-важното е да избегнете скъпо страниране чрез skip и take (използвайте $lt /$gt на _id вместо това).
• Има ограничение за максималната дължина на индекса в mongodb от по-малко от 1024 байта. Въпреки че не са красиви, URL адресите могат да бъдат много по-дълго . Ако някой въведе по-дълъг охлюв, той няма да бъде намерен, защото безшумно е изпуснат от индекса.
• Добра идея е да имате последователен интерфейс, т.е. да използвате един и същи тип _id на всички или поне на повечето от вашите обекти. В моя код имам едно изключение, при което използвам специален хеш като идентификатор, защото стойността не може да се промени, колекцията има изключително високи скорости на запис и е голяма.
• Да приемем, че искате да направите връзка към статията във вашия интерфейс за управление (не публичния сайт), коя връзка бихте използвали? Обикновено id, но сега id и slug са еквивалентни. Сега един обикновен бъг (като разрешаване на празен охлюв) би бил труден за възстановяване, тъй като потребителят дори вече не може да отиде до интерфейса за управление.
• Ще се справите с проблеми с набора от знаци. Бих предложил дори да не използвате slug за търсене на статията, а хеш на slug .

По същество ще завършите със схема като

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