Wada wydajności przy użyciu sluga jako klucza podstawowego/_id w mongo?

Moim zdaniem nie. W większości scenariuszy różnica w wydajności będzie nieistotna (z wyjątkiem stronicowania ), ale

• Powstaje stara dyskusja o zastępczych kluczach podstawowych. „Ślimak” nie jest bardzo naturalnym kluczem. Tak, musi być unikalny, ale jak już wspomniałeś, zmiana ślimaka nie powinna być niemożliwa. Samo to powstrzymałoby mnie od zawracania sobie głowy...
• Mając monotoniczny _id klucz może uchronić Cię przed wieloma bólami głowy, co najważniejsze, aby uniknąć kosztownego stronicowania poprzez skip i take (użyj $lt /$gt na _id zamiast tego).
• Istnieje limit maksymalnej długości indeksu w mongodb mniej niż 1024 bajty. Chociaż nie są ładne, adresy URL mogą być dużo dłużej . Jeśli ktoś wpisałby dłuższy ślimak, nie zostałby znaleziony, ponieważ został po cichu usunięty z indeksu.
• Dobrym pomysłem jest posiadanie spójnego interfejsu, tj. używanie tego samego typu _id na wszystkich, a przynajmniej na większości twoich obiektów. W moim kodzie mam jeden wyjątek, w którym używam specjalnego skrótu jako identyfikatora, ponieważ wartość nie może się zmienić, kolekcja ma bardzo wysokie współczynniki zapisu i jest duża.
• Załóżmy, że chcesz utworzyć link do artykułu w interfejsie zarządzania (nie w witrynie publicznej), którego linku byś użył? Zwykle identyfikator, ale teraz identyfikator i ślimak są równoważne. Teraz prosty błąd (taki jak zezwolenie na pusty slug) byłby trudny do odzyskania, ponieważ użytkownik nie mógł już nawet przejść do interfejsu zarządzania.
• Będziesz zajmował się problemami z zestawami znaków. Proponuję nawet nie używać ślimaka do wyszukiwania artykułu, ale hasz ślimaka .

Zasadniczo otrzymasz schemat taki jak

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