Анализирането на ObjectId от заявка не би било трудно (така че не съм сигурен защо това е проблем?). Ако целта е да създадете URL адреси, които могат да се въвеждат, тогава наличието на по-кратък и „по-приятелски“ URL би било ценно.
Не можете да вземете 12-байтово число, което е гарантирано уникално в шардирана настройка на MongoDB, и да го кондензирате до по-малко от 12 байта и то да бъде гарантирано уникално (вие споменахте под седем знака например).
От документи , MongoDB ObjectId се състои от:
- 4-байтово времево клеймо
- 3-байтов идентификатор на машина
- 2-байтов идентификатор на процеса
- и 3-байтов брояч.
Така че ще трябва или да пожертвате част от ObjectId (и следователно шардинг), или да измислите алтернативен формат за създаване на Id, който е индексиран.
Въпреки че бихте могли да хеширате идентификатора потенциално, отново могат да възникнат конфликти, които бихте искали да кодирате (отново, не можете да намалите 12 байта до 4 байта и да гарантирате уникалност). И ако има възможни конфликти (и ще има, ако намалите общия брой налични битове), така или иначе ще ви е необходима някаква вторична таблица (и ще трябва да създадете индекс, за да преминете от генериран ID към ObjectId) .
Резултатни опции:
- Премахнете нормално значимите битове -- ако направите това, не разделяне на колекцията
- Създайте свое собствено решение за уникален идентификатор (и ако е в уеб ферма, може в крайна сметка да изглежда много подобно на MongoDB, за да се справи с уникалността)
- използвайте ObjectId като дълго число и изпълнете съкратен алгоритъм върху него (ще трябва първо да бъде разбит на по-малки части, тъй като надвишава числената точност на JavaScript от 53 бита), опитайте този алгоритъм например =кодиране то (ще завърши с около 17 знака)
- използвайте нещо друго, по-кратко, но уникално като идентификатор за вашите документи
- Най-лесният:Просто приемете, че идентификаторите са дълги. :)
(Не е ясно защо браузърът трябва да прави това преобразуване – защо ще има ObjectID на документа?)
