Не, изобщо не е лошо и всъщност е вграденият ObjectId е доста голям в индекса, така че ако смятате, че имате нещо по-добро, тогава сте повече от добре дошли да промените стойността по подразбиране на _id поле към каквото и да е.
Но и това е голямо но , има някои съображения, когато решавате да се отдалечите от формулирания по подразбиране ObjectId , особено когато използвате автоматично увеличаващите се _ids, както е показано тук:https://docs.mongodb.com/v3.0/tutorial/create-an-auto-incrementing-field
Многонишковата обработка не е толкова голям проблем, защото findAndModify и атомните ключалки всъщност могат да се погрижат за това, но тогава просто се сблъсквате с първия си проблем. findAndModify не е нито най-бързата, нито най-леката функция и има значителни спадове в производителността при редовното й използване.
Вие също така трябва да помислите за режийните разходи да направите това сами, дори без findAndModify . За всяка вложка ще ви трябва допълнителна заявка. Представете си, че имате уникален идентификатор, който трябва да заявявате за уникалността всеки път, когато искате да вмъкнете. В крайна сметка скоростта ви на вмъкване ще спадне до обхождане и времето за заключване ще се увеличи.
Разбира се ObjectId наистина е добър в това да бъде уникален, без да се налага да проверява или формулира собствената си уникалност, като докосва базата данни преди вмъкването, следователно няма тези допълнителни разходи.
Ако все още смятате, че един цяло число _id отговаря на вашия сценарий, тогава го направете, но имайте предвид описаните по-горе режийни разходи.
