MongoDB: недостатки от пользовательских ObjectID на основе строки - PullRequest
Новая
       4

MongoDB: недостатки от пользовательских ObjectID на основе строки

0 голосов
/ 15 апреля 2020

Используя 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
      shareID: {type: String, required: true},            //option 1 (e.g. dIxELcJsbLC)            
      _id: {type: String, required: true},                //option 2

    }, {collection: 'books'});

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

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

Я думал о варианте 1: внутреннее использование собственных идентификаторов объектов (для отношений между различными схемами ) и сохраните дополнительный shareID для общего доступа (mydomain.com/book/dIxELcJsbLC-title), даже несмотря на то, что поиск этой книги на основе shareID в базе данных huuuge, возможно, когда-нибудь, может занять гораздо больше времени, чем ссылки на нативный ObjectID.

Проблема, о которой я здесь говорю, почти такая же, как на веб-сайте stackoverflow. URL этого вопроса включает в себя номер 61233180, который явно является своего рода идентификатором, который используется для загрузки этого документа из базы данных, но я серьезно сомневаюсь, что это также фактический ObjectID / первичный ключ этого вопроса в базе данных. Ты знаешь, что я имею в виду? Есть мысли по этому поводу? Заранее благодарим за любой обмен опытом.

...