Parsing af ObjectId fra en anmodning ville ikke være svært (så jeg er ikke sikker på, hvorfor det er et problem?). Hvis målet er at lave typebare URL'er, vil det være værdifuldt at have en kortere og "venligere" URL.
Du kan ikke tage et 12 byte-nummer, der er garanteret unikt i en shard MongoDB-opsætning, og kondensere det til færre end 12 bytes og få det garanteret unikt (du nævnte f.eks. under syv tegn).
Fra dokumenterne , MongoDB ObjectId består af:
- et 4-byte tidsstempel
- en 3-byte maskin-id
- et 2-byte proces-id
- og en 3-byte tæller.
Så du bliver enten nødt til at ofre en del af ObjectId (og dermed sharding), eller udtænke et alternativt Id-oprettelsesformat, der er indekseret.
Selvom du potentielt kan hash ID'et, kan der igen opstå konflikter, som du gerne vil kode for (igen, du kan ikke tage 12 bytes ned til 4 bytes og garantere unikhed). Og hvis der er mulige konflikter (og det vil være, hvis du reducerer det samlede antal tilgængelige bits), har du alligevel brug for en slags sekundær tabel (og du skal oprette et indeks for at gå fra genereret ID til ObjectId) .
Resulterende muligheder:
- Fjern normalt signifikante bits – hvis du gør dette, lad være skære samlingen
- Udform din egen, din egen unikke ID-løsning (og hvis den er i en webfarm, kan den ende med at ligne MongoDB's for at håndtere unikhed)
- brug ObjectId'et som et langt tal og kør en afkortningsalgoritme på det (det skal først opdeles i mindre bidder, da det overstiger JavaScripts numeriske præcision på 53 bit), prøv denne algoritme for eksempel =indkode det (vil ende på omkring 17 tegn)
- brug noget andet kortere, men unikt som id for dine dokumenter
- Nemmeste:Bare accepter, at Id'erne er lange. :)
(Det er ikke klart, hvorfor browseren skulle udføre denne konvertering - hvorfor skulle den have dokumentets ObjectID?)