としてこのクエリをフレームないに条件を追加します。 SQLでは、作成するフィールドインデックスを明示的に指定する必要があります。 CouchDBでは、カスタム関数作成インデックスを作成するので、必要に応じてより具体化することができます。
function (doc) {
if (doc.name && doc.state && doc.country)
emit([doc.name, doc.state, doc.country], doc);
}
キー["my_name", "my_state", "my_country"]
を検索このビューを使用して検索するには:あなたが名前の検索などの単純なことのためにインデックスをしたい場合は、州および国のビューがちょうどmap関数であるフィールド。マップの検索可能な結果が辞書的にソートされているため、配列のプレフィックス(name
で検索しますが、state
とcountry
ではない)の名前、州、国のサブセットで照会することができます。
原則として、ビューはクエリのいくつかの機能でインデックスされ、SQLクエリほど柔軟ではありません。それらは一度実行され、ディスクに保存され、新しい/変更されたデータに対して段階的に計算されます。分散システム(CouchDBが設計されている)で非効率的なことをするのは難しいことを心配してください。インデックスのない複雑な結合...多くの場合、リレーショナルモデルのテーブルの人為的な分割は、ドキュメントが利用可能であり、いくつかの結合は必要ありません。
CouchDBとSQLの簡単な比較については、this chapter of The Definitive Guide本と他の章を参照してください。また、ビューの詳細については、wikiを参照してください。
私はここで本当の問題は、あなたがフィールドの高いX番号を持っていて、ユーザーが検索基準のどの組み合わせがわからないときどうするかだと思いますフィルタリングしたい20個のフィールドがある場合は、潜在的な検索条件のすべての組み合わせを処理するのに必要な2.432902e + 18ビューを作成することはできません。あなたは20のビューを持つことができますし、何とかビューを交差しようとしますか? –
CouchDBはユニバーサルデータベースではありません。特定のユースケースのデータ構造(文書スキームとビュー)を設計する必要があります。多次元クエリで、余分なプラグインなしでは利用できませんが(GeoCouchやlucene/elasticsearchなど)、避けようとするかもしれません。 SQLをビューに単純に変換し、リレーショナル・デザインをJSON文書にマッピングするだけでは不十分です。 –