6

私のアプリでは、mongo に ObjectId メソッドを介して注文 ID を生成させています。

しかし、ユーザー テストでは、注文 ID が人間的に「威圧的」であるという懸念がありました。つまり、注文について電話で誰かと話し合う必要がある場合、24 文字の英数字を読み上げるのは少し面倒です。

同時に、「人間がアクセスできる」IDとmongoが内部で使用するIDの2つの異なるIDを保存する必要はありません。

だから私の質問はこれです - mongo objectId 文字列の長さ6または8の部分文字列を選択して、一意であると確信できる方法はありますか?

たとえば、このようなmongo objectidがある場合

id = '4b28dcb61083ed3c809e0416'

多分私は取ることができた

human_id = id.substr(0,7);

そして、注文に対して常に一意のIDを取得するようにしてください...

もちろん、利点は、これらが注文であり、人間が作成したものであり、ミリ秒あたり数百万ではないことです。一方、2 つの注文が同じ短縮 ID を持っていたら、それは本当に問題になります...

--- 分かりやすい説明 ---

私の質問をするより良い方法はこれだと思います：

たとえば、mongo id の最後の 6 文字だけを使用することにした場合、これらの 6 文字だけが特定の週に繰り返される「確率」の尺度はありますか?

特定の数の mongo が並行して実行されている場合、週に特定の数のユーザーがいる場合など。

4

2 に答える 2

1

実際に何を選択し、ID (実際_idには MongoDB ストレージ内) は完全にあなた次第です。_id一意である限り保持できる有用なデータがある場合は、そうしてください。URLエンコーディングに有効なものでなければならない場合は、そうしてください。

デフォルトでは、 を指定しない場合、そのフィールドには、好き嫌い_idの値が入力されます。しかし、明示的に使用すると、必要なものが得られます。

さらに覚えておくべきことは、追加の一意のインデックス フィールドを指定した場合でも、order_idMongoDB はクエリ プランのそのインデックスと他のインデックスを実際にチェックして、どれを使用するのが最適かを確認する必要があるということです。しかし、_idあなたの鍵があなたの鍵だった場合、計画はあきらめて「主鍵」に行き詰まり、これははるかに高速になります。

そのため、一意であることを確認できる限り、独自のIDを作成してください。

于 2014-02-01T14:05:18.243 に答える