14

RESTful サービスで初めて mongoDB を使用しています。以前は、SQL データベースの id 列は増分整数だったので、RESTful エンドポイントは のようになります/rest/objectType/1。mongoDB の ObjectId を同じ役割で使用してはならない理由はありますか、それとも個別のインクリメント整数 ID 列を維持し、これを URL に使用する方が賢明ですか?

4

2 に答える 2

16

ObjectIds を RESTful API で何度か使用してきたが、最大の欠点は、きれいな URL を持つという点でノイズが非常に多いことです。16 進数のままにするか、非常に大きな整数に変換するかのいずれかを行うと、どちらもやや不親切な URL になります。

/rest/resource/52435dbecb970072ec3a780f
/rest/resource/25459211534898951476729247759

URL に「タイトル」を追加して (StackOverflow のように)、もう少し使いやすくしました。

    /rest/resource/52435dbecb970072ec3a780f/FriendlyResourceName

もちろん、「タイトル」はソフトウェアでは無視されますが、ユーザーはそれを見て、クレイジーな ID セグメントを精神的に無視できます。

それらを公開することによってインフラストラクチャから学ぶことができる有用なものはほとんどありません。

  1. タイムスタンプ
  2. マシン ID
  3. プロセス ID
  4. ランダム増分値

マシン ID を収集する可能性がある (これは通常、 を作成しているクライアントの数を示しますObjectId) 以外には、それほど多くはありません。

ObjectIds はランダムではないため、セキュリティのために使用できませんでした。常にデータを保護する必要があります。それらは明らかな方法で増加しないかもしれませんが、力ずくで他のリソースを見つけるのは簡単です. ただし、以前に自動インクリメント ID を使用していた場合、これは新しい問題ではありません。

常に多くの新しいドキュメントを作成していないことがわかっている場合は、ここにあるパターンのいずれかを使用して、より単純な ID を作成する価値があるかもしれません。私が作成した 1 つのアプリでは、URL に表示されるドキュメント ID の一部に auto-inc 手法を使用し、Ajax 専用のドキュメント ID にはObjectIds を使用しました。URL を簡単に「入力」できるようにしたかったのです。の形式はObjectId、エンド ユーザーが簡単に入力することはできません。これは、MongoDB の強みの 1 つであり、任意の_id形式を使用できます。:)

于 2013-09-26T14:39:46.777 に答える
8

ObjectIdインクリメント カウンターを維持することがボトルネックになる可能性があるため、sを使用する方が賢明です。また、ObjectIdタイムスタンプが含まれて単調であるため、クエリの最適化に役立ちます。

推測することはObjectIdsできますが、これは ID のインクリメントには間違いなく当てはまるため、以前はあいまいさによるセキュリティに依存していなかったのではないかと思います。問題はありません。

小さな欠点ではありますが、サーバーでの作成時間がユーザーに漏れることです。つまり、ユーザーがこれを として識別できれば、ObjectIdオブジェクトの作成時間をリバースエンジニアリングできます。それが私が見る唯一の潜在的な問題です。

于 2013-09-26T14:20:22.013 に答える