データベースにまだ存在しないオブジェクトのIDを生成することは悪い習慣ですか？
ここに状況があります：
MongoデータベースAとMongoデータベースBがあります。
データベースBのコレクションの1つに存在するsomeModelと呼ばれるビジネスコンセプト/ Mongoオブジェクトがあります。
ここに質問があります。このsomeModelを生成する方法は、データベースAからの他のオブジェクトのデータに基づいています。既存のsomeModels（実際にはデータベースBに実際に存在するオブジェクト）と、データの集まりである存在しないものをすべてロードしたい場合があります。データベースAのコレクションから（前述のとおり）。
これで、既存のsomeModelesには一意であり、作成時に生成されたMongo IDがありますが、存在しないsomeModelsにはまだIDがありません。私たちがそれを必要とする理由は、識別/照合の目的（フロントエンドとバックエンドの間）のためです。
結論としては、Mongooseを介してIDを生成することを考えており、IDが一時的（保存されるまで）であり、識別/照合の目的でのみ使用される場合でも、常に完全にDTOが入力されていますが、一度保存されると「temporary id」は永続的になります。
事業を具体的にするのではなく、一般的な問題のように聞こえるように意図的に非常に抽象化しましたが、詳細が必要な場合は、お問い合わせください。
したがって、それが問題です。データベースに存在しないオブジェクトのIDを生成することが、この特定のコンテキストでは悪い習慣であるかどうかです。
皆さんありがとう、あなたの時間とサポートに感謝します！
多くの場合、それは依存します。一般的な回答を求めたので、ここでは特定のテクノロジーから独立したものを提供しようとしています。
IDの許可されたドメイン範囲が巨大であり、データベースに毎秒数百万のIDを生成させない場合、妥当な時間内に使用可能なIDが不足するリスクが小さい場合は、それらのIDを使用できます。そして、あなたが望むもののためにそれらを使用してください（たとえそれがあなたがそれらを一時的にだけ使用し、その後それらを捨てるという意味であっても）.
一方、上記の前提条件が満たされていない場合は、IDが不足したり、IDの衝突が発生したりしないように注意する必要があります。
たとえば、GUIDをIDとして使用すると（128ビット数のドメイン範囲を使用）、短時間で大量のIDを作成しない限り（特に、衝突を制限できる場合）、IDの衝突が発生する可能性は非常に低くなります。特別な使用例をテストします。
また、今日は巨大に見えるドメイン範囲が明日はそれほど大きく見えない可能性があることにも注意してください（最良の例は、使用可能なアドレスが年々不足しているIP V4プロトコルです）。
実際には、「データベースに存在しないオブジェクトのIDを生成しています[B]」。このオブジェクトは存在します。
@ AvetisG、someModelエンティティとsomeModelエンティティの属性が分離されています。アプリケーションロジックはsomeModelエンティティのマスターであり、AおよびBはそれぞれsomeModelエンティティ属性のいくつかのマスターです。あなたのコンテキストでは、マスター（ロジック）に一意のsomeModelエンティティ（およびそのID）があることは非常に有効ですが、AまたはB、あるいはその両方にはまだ属性がありません。
特定の状況で意味があるかどうかはわかりませんが、私にとっては、ID（someModelエンティティへのリンク）をBに保持し、Aに保持しない理由はないようです。IDを生成するオプションを検討してください（ someModelエンティティを作成します）、Bには存在しないすべての「データの複合体」に対して、それらを格納します。 someModelエンティティのライフサイクルがフォームデータの観点からより明確になります。 （エンティティストレージなしの設定ストレージで実行することも問題です。）