Att analysera ObjectId från en begäran skulle inte vara svårt (så jag är inte säker på varför det är ett problem?). Om målet är att skapa skrivbara webbadresser skulle det vara värdefullt att ha en kortare och "vänligare" webbadress.
Du kan inte ta ett nummer på 12 byte som är garanterat unikt i en fragmenterad MongoDB-installation och kondensera det till färre än 12 byte och få det garanterat unikt (du nämnde till exempel under sju tecken).
Från dokumenten , MongoDB ObjectId består av:
- en 4-byte tidsstämpel
- en 3-byte maskinidentifierare
- ett 2-byte process-id
- och en 3-byte-räknare.
Så du måste antingen offra en del av ObjectId (och därmed sharding), eller skapa ett alternativt ID-skapande format som indexeras.
Även om du potentiellt kan hasha ID:t, kan det återigen uppstå konflikter som du skulle vilja koda för (igen, du kan inte ta 12 byte ner till 4 byte och garantera unikhet). Och om det finns konflikter möjliga (och det kommer att finnas om du minskar det totala antalet tillgängliga bitar), behöver du ändå någon sorts sekundär tabell (och du skulle behöva skapa ett index för att gå från genererat ID till ObjectId) .
Resultatalternativ:
- Ta bort normalt signifikanta bitar – om du gör det, gör inte det skära samlingen
- Utforma din egen unika ID-lösning (och om den är i en webbfarm kan den sluta se väldigt lik MongoDBs för att hantera unikhet)
- använd ObjectId som ett långt nummer och kör en förkortningsalgoritm på det (det måste först delas upp i mindre bitar eftersom det överskrider JavaScripts numeriska precision på 53 bitar), prova den här algoritmen till exempel =koda det (kommer att sluta på cirka 17 tecken)
- använd något annat kortare men unikt som ID för dina dokument
- Enklast:Acceptera bara att ID:n är långa. :)
(Det är inte klart varför webbläsaren skulle behöva göra den här konverteringen – varför skulle den ha dokumentets ObjectID?)