私が見たいくつか：
- URLには適していません。 Twitterは、http://twitter.com/gatesvp のようなURLを教えてくれます。 、ObjectIdを使用すると、http://example.com/ab12ab12ab12ab12ab12ab12 のようなURLを取得します。 。
- ObjectIdのシャーディングは非常に不十分です。これは実際にはランダムではなく、ある程度シーケンシャルであるため、新しいユーザーはランダムに配布するのではなく、シャード上にクラスター化します。
- 多くの場合、別の一意の識別子が必要です。ほとんどのWebサイトには、一意の電子メールまたは一意のユーザー名が必要です。はい、「ユーザー名」に一意のインデックスを作成できますが、2つの一意のインデックスがあります。1つは便利なもので、もう1つは単なる乱数です。
- これはどこでも参照できます。ユーザーのデータは通常、すべて「userId」へのポインターを持つ複数のコレクションに分散されます。 ObjectId（またはGuid）があるということは、これらの大きなIDを常にコピーして貼り付け、DBに保存していることを意味します。
どこに転送しましたか？ユーザーのデータをMongoDBに保存し始めると、IDは別のDBへの転送の問題を最小限に抑えることができます。最近のすべてのDBは、主キーIDとして何らかの形式の文字列またはバイナリを処理できるため、転送は問題なく機能するはずです。ただし、複雑さのほとんどはIDとは関係ありません。