5

ちょっと主観的な質問ですが、クライアント側でmongodb_idsを操作することについていくつか懸念があります。RESTfulリソースやアイテムの小さなコレクションでの作業には、s52ruf6wstやxR2ru286zjIのようなものを使用する方がよいでしょう。

1）バックエンドデータベースのプロプライエタリ実装（_idフィールド名と実装）に依存し始めています。この_idsを使い続けると、後でバックエンドデータベースを置き換えるのが難しくなります。

2）mongo _idsを含む巨大な醜いURLがあります（RESTエンドポイントの場合でも-私はそれが好きではありません）

3）ハッカーや「好奇心旺盛なユーザー」にとって、どのバックエンドデータベースが使用されているかが明らかになります。

私が見るように、ほとんどのWebアプリケーションは、id、uid、uuidがどのように見えるかについて独自の規則を使用しており、（dbベンダーによる単純で醜い実装を使用するよりも）よりプロフェッショナルに見えると思います。

したがって、問題は、標準のmongo _idを使用して、バックエンドとフロントエンドでそれらを使用するのが適切な場合です。そして、状況を改善するために何ができるでしょうか？

4

2 に答える 2

8

標準のmongo_idsを使用するのが適切な場合

いつも。単に気に入らない場合を除いて。しかし、あなたの個人的な好みはセキュリティとは何の関係もありません。MongoのオブジェクトIDは、他のどの識別子タイプ（整数、UUIDなど）よりも本質的に安全性が低いわけではありません。

ObjectIDは、クラスター全体で一意になるように設計されています。mongodbは分散DBであるため、これは非常に重要です。また、優れた特性もあります。値は時間とともに単調に増加します。このプロパティは、役立つ場合と役に立たない場合があります。

于 2013-01-11T11:43:05.043 に答える
2

1）バックエンドデータベースのプロプライエタリ実装（_idフィールド名と実装）に依存し始めています。この_idsを使い続けると、後でバックエンドデータベースを置き換えるのが難しくなります。

ここで、抽象化レイヤー、フレームワーク、ODM（ORM）が登場します。これらは、複数の異なるタイプのデータベースをクエリするための標準化されたレイヤー（つまり、Doctrine 2）を提供します。例として、使用しているデータベースに応じて、id多くのORMで変換されます。_idIDid

前に述べたように、にObjectIdは固有のセキュリティ上の欠陥はありませんObjectId。時間の部分があるとしても、この時間の部分を使用して次のオブジェクトを簡単に決定することはできないため、他のユーザーにとっては一般的にはそれほど有用ではありません（自動インクリメントとは異なります）。 ID）。これを確実に行う唯一の方法は、これまでのすべての時間とすべてのpid番号をテストして、非表示のオブジェクトが存在するかどうかを検出することです。したがって、URLをクロールすることはまったく簡単ではなくObjectId、実際、その正確な理由からSEOにあまり適していません。しかし、はい、彼らはあなたが使用しているデータベースを知ることができました。

そうは言っても、そうです、彼らは醜いですが、@ Sergioが言うように、彼らはとても長くて醜いです。自分で作るのも同じくらい悪いことです。の16進表現をbase64エンコードすることで、少し縮小できると思いますObjectId。

しかし、あなたが本当にそれを必要としているかどうかはわかりません。

于 2013-01-11T11:53:31.290 に答える