A mio avviso, no. La differenza di prestazioni sarà trascurabile per la maggior parte degli scenari (tranne il paging ), ma
- Viene fuori la vecchia discussione sulle chiavi primarie surrogate. Una "lumaca" non è una chiave molto naturale. Sì, deve essere unico, ma come hai già sottolineato, cambiare lo slug non dovrebbe essere impossibile. Questo da solo mi impedirebbe di disturbare...
- Avere un
_idmonotono chiave può salvarti da una serie di mal di testa, soprattutto per evitare costosi paging tramiteskipetake(usa$lt/$gtsul_idinvece). - C'è un limite alla lunghezza massima dell'indice in mongodb inferiore a di 1024 byte. Sebbene non siano belli, gli URL possono essere molto più lungo . Se qualcuno avesse inserito uno slug più lungo, non sarebbe stato trovato perché è stato eliminato silenziosamente dall'indice.
- È una buona idea avere un'interfaccia coerente, ovvero utilizzare lo stesso tipo di
_idsu tutti, o almeno, sulla maggior parte dei tuoi oggetti. Nel mio codice, ho una singola eccezione in cui utilizzo un hash speciale come id perché il valore non può cambiare, la raccolta ha velocità di scrittura estremamente elevate ed è grande. - Diciamo che vuoi collegarti all'articolo nella tua interfaccia di gestione (non al sito pubblico), quale link useresti? Normalmente l'id, ma ora l'id e lo slug sono equivalenti. Ora un semplice bug (come consentire uno slug vuoto) sarebbe difficile da recuperare, perché l'utente non può nemmeno più accedere all'interfaccia di gestione.
- Ti occuperai di problemi con i set di caratteri. Suggerirei di non usare nemmeno lo slug per cercare l'articolo, ma l'hash dello slug .
In sostanza, ti ritroverai con uno schema come
{ "_id" : ObjectId("a237b45..."), // PK
"slug" : "mongodb-is-fun", // not indexed
"hash" : "5af87c62da34" } // indexed, unique
