1

そのため、MySQL で自動インクリメント プライマリ ID によって送信を検索することに慣れていますが、MongoDB ORM ラッパーである Mongoose を使用した後、Mongo はコレクション内にデータを異なる方法で保存するため、従来の自動インクリメント ID。

通常、私は自分の URL を次のように構成するため、現在、提出物を取得する方法を見つけようとして立ち往生しています。

submission/34/category/slug-goes-here.

現在、Mongo では UUID に基づく醜い文字列になっているため34、URL にそれを表示する必要はありませんが、提出物を検索するために一意の URL が必要です。

提出物をデータベースに挿入すると、ある種の6文字のハッシュが生成され、そのように検索されるというsetメソッドを持つことを考えていますzhXk40。

このようにすると、パフォーマンスのトレードオフがどうなるか疑問に思っています。スラッグに制約をつけて、それをスラッグで調べて、カテゴリが一致していることを確認したら、もっと効率的でしょうか? いずれにしても、カテゴリとスラッグが一致するかどうかを確認する必要がありますが、この場合 ID が本当に必要かどうかはわかりません。

ルートを作成し、そのルートに基づいてデータベースからデータを検索するためのベストプラクティスは何ですか?

4

2 に答える 2

0

最初に知っておくべきことは 、_idプロパティが必ずしも「醜い」ObjectId文字列であるとは限らないということです。

実際には、_idコレクション内で一意である必要があるだけなので、自動インクリメント ID を使用する場合は問題ありませんが...

データベース内でシャーディングを使用する予定がある場合、自動インクリメント フィールドを使用するの_idはやり過ぎです。

なんで？ここで受け入れられた回答を読んでください: MongoDBで自動インクリメントを実装する必要がありますか?

私のアプリケーションでは、それを分割するつもりはないので、最終ユーザーにとって使いやすいように、インデックス付きの数値 ID を使用します。内部的にはすべての参照がObjectIds です。

また、MongoDB で自動インクリメント フィールドを作成するための優れたチュートリアル: http://docs.mongodb.org/manual/tutorial/create-an-auto-incrementing-field/

于 2013-03-05T12:07:24.843 に答える
-2

おい！ここでベストプラクティスを本当に知ることができれば、私たちは皆、より良くなるでしょう. トーキング・ヘッズはまだ話し続けており、しばらくの間そうなるでしょう。

これにどのようにアプローチするかは、できる限りきれいにすることです。セマンティックにするために使用可能なテキスト文字列があれば、それが最善のケースです。

それができない場合は、あなたが提案したハッシュのものを使用します。

両方のソリューションの課題は、独自性を維持することです。つまり、保存する前にルックアップします。

パフォーマンスに関しては、SQL と同じです。物事を調べるために使用するものに索引を付けます。Mongo は複合インデックスに適しているため、カテゴリ名とハッシュは非常に迅速に検索されます。

于 2013-03-05T06:38:15.547 に答える