Analizzare ObjectId da una richiesta non sarebbe difficile (quindi non sono sicuro del motivo per cui questo è un problema?). Se l'obiettivo è creare URL digitabili, sarebbe utile disporre di un URL più breve e "più amichevole".
Non puoi prendere un numero di 12 byte garantito univoco in una configurazione MongoDB frammentata e condensarlo a meno di 12 byte e garantirne l'univocità (ad esempio, hai menzionato sotto sette caratteri).
Dai documenti , MongoDB ObjectId è costituito da:
- un timestamp a 4 byte
- un identificatore di macchina a 3 byte
- un ID processo a 2 byte
- e un contatore a 3 byte.
Quindi, dovrai sacrificare una parte dell'ObjectId (e quindi il partizionamento orizzontale) o ideare un formato di creazione ID alternativo che sia indicizzato.
Sebbene tu possa potenzialmente eseguire l'hashing dell'ID, ancora una volta possono sorgere conflitti per i quali vorresti codificare (di nuovo, non puoi ridurre da 12 byte a 4 byte e garantire l'unicità). E se sono possibili conflitti (e ce ne saranno se riduci il numero totale di bit disponibili), avrai comunque bisogno di una sorta di tabella secondaria (e dovrai creare un indice per passare dall'ID generato a ObjectId) .
Opzioni risultanti:
- Rimuovi i bit normalmente significativi:se lo fai, non frantuma la raccolta
- Progetta la tua soluzione ID univoca (e se si trova in una web farm, potrebbe sembrare molto simile a quella di MongoDB per gestire l'unicità)
- usa ObjectId come numero lungo ed esegui un algoritmo di riduzione su di esso (dovrà essere prima suddiviso in blocchi più piccoli poiché supera la precisione numerica di JavaScript di 53 bit), prova ad esempio questo algoritmo =encode it (finirà circa 17 caratteri)
- usa qualcos'altro più breve, ma unico come ID per i tuoi documenti
- Più semplice:accetta solo che gli ID siano lunghi. :)
(Non è chiaro il motivo per cui il browser dovrebbe eseguire questa conversione:perché dovrebbe avere l'ObjectID del documento?)
