MongoDB с Mon goose: быстрый и короткий индексированный идентификатор документа

Question

Используя MongoDB 4.2.5 и Mon goose в среде MEAN, у меня есть две коллекции (книги и авторы), тогда как многие книги могут быть связаны с одним автором.

AuthorSchema = new Schema({
       //...
        books: [{type: Schema.Types.ObjectId, ref: 'Book', required: false}] //option 1
        books: [{type: String, ref: 'Book', required: false}]                //option 2
    }, {collection: 'authors'});

BookSchema = new Schema({
        _id: {type: Schema.Types.ObjectId, required: true},   //option 1
        _id: {type: String, required: true},                  //option 2
        shareID: {type: String, required: true},              //option 2 (e.g. dIxELcJsbLC)
    }, {collection: 'books'});

Моя цель - создать пользовательские идентификаторы ObjectID для книг, которые имеют меньшую длину, чем собственный ObjectID MongoDB, но, конечно, все еще уникальны - что-то вроде Youtube использует для каждого видео (например, dIxELcJsbL C) , который также можно легко поделиться в Интернете. Теперь проблема в том, что я не могу просто создать свою собственную уникальную строку и привести ее к ObjectID, так как ее структура должна соответствовать определенным структурным правилам (12 байтов или строка из 24 шестнадцатеричных символов), что в значительной степени просто оставляет мне возможность 2. То есть, предоставьте обычную пользовательскую строку UUID и объявите ее ._id документа книги.

Насколько я знаю, работа с пользовательским идентификатором в коллекциях всегда работает хуже, чем собственные идентификаторы объектов в долгосрочной перспективе. Как я могу иметь оба: ObjectID, которые работают настолько эффективно, насколько это возможно, и в то же время их легко можно совместно использовать в сети в компактном виде?

Я думал об использовании внутренних идентификаторов объектов для внутренних целей (для отношений между различными схемами) и сохранить дополнительный shareID для общего доступа (mydomain.com/book/dIxELcJsbLC-title), даже несмотря на то, что нахождение этой книги на основе shareID в базе данных huuuge, возможно, когда-нибудь, может занять больше времени, чем ссылки на нативный ObjectID. Я надеюсь, вы понимаете, о чем я. Другим примером этого подхода, вероятно, является stackoverflow. Просматривая URL этого сайта, вы можете увидеть целочисленное значение, которое явно является своего рода идентификатором в базе данных, но, безусловно, не будет основным / индексированным значением, я прав? Таким образом, они используют короткий идентификатор для внешнего воздействия, а также другой идентификатор, служащий внутренним целям (связывание документов). Есть мысли на этот счет? Заранее благодарим за любой обмен опытом.

Answer 1

Не требуется, чтобы поле _id содержало данные типа ObjectId. Вы можете использовать любой тип данных, какой захотите, если он индексируется одной записью, то есть значение не может быть массивом, а индекс {_id:1} не может быть многоключевым, объекты как _id допускаются.

Если вы преобразуете свое пользовательское значение в ObjectId, оно все равно становится 12-байтовым значением, поэтому вы теряете любое преимущество, делая его короче.

Пока индексируется поле shareId поиск документа по его полю shareID не должен работать значительно иначе, чем поиск документа по его _id.

. * * * * * * * * * * * * Единственное, что особенного в _id, это: - он индексируется автоматически - уникальность обеспечивается - он не может быть обновлен в документе (вам придется удалить и заново вставить его с новым _id)