Analýza ObjectId z požadavku by nebyla obtížná (takže si nejsem jistý, proč je to problém?). Pokud je cílem vytvářet typovatelné adresy URL, pak by bylo cenné mít kratší a „přátelštější“ adresu URL.
Nemůžete vzít 12bajtové číslo, které je zaručeně jedinečné ve sharded nastavení MongoDB, a zhustit ho na méně než 12 bajtů, aby bylo zaručeno jedinečné (zmínili jste se například pod sedmi znaky).
Z dokumentů , MongoDB ObjectId se skládá z:
- 4bajtové časové razítko
- 3bajtový identifikátor počítače
- 2bajtové ID procesu
- a 3bajtové počítadlo.
Takže budete muset buď obětovat nějakou část ObjectId (a tedy sharding), nebo navrhnout alternativní formát pro vytváření ID, který bude indexován.
I když byste mohli potenciálně hashovat ID, opět mohou nastat konflikty, pro které byste chtěli kódovat (znovu nemůžete snížit 12 bajtů na 4 bajty a zaručit jedinečnost). A pokud jsou možné konflikty (a budou, pokud snížíte celkový počet dostupných bitů), budete stejně potřebovat nějakou sekundární tabulku (a budete muset vytvořit index, abyste přešli z vygenerovaného ID na ObjectId) .
Výsledné možnosti:
- Odstraňte běžně významné bity – pokud to uděláte, neodstraňujte to střep sbírku
- Vymyslete si své vlastní řešení jedinečného ID (a pokud je na webové farmě, může nakonec vypadat velmi podobně jako MongoDB, aby bylo možné zvládnout jedinečnost)
- použijte ObjectId jako dlouhé číslo a spusťte na něm zkracovací algoritmus (bude ho muset nejprve rozdělit na menší části, protože přesahuje numerickou přesnost JavaScriptu 53 bitů), vyzkoušejte například tento algoritmus =kódovat to (bude mít přibližně 17 znaků)
- jako ID pro vaše dokumenty použijte něco jiného kratšího, ale jedinečného
- Nejjednodušší:Přijměte, že ID jsou dlouhá. :)
(Není jasné, proč by prohlížeč musel tuto konverzi provádět – proč by měl mít ObjectID dokumentu?)