2

たとえば、couchDB で保存するドキュメントがあり、そのドキュメントは次のようになります。

{
   "email": "lorem@gmail.com",
   "name": "lorem",
   "id": "lorem",
   "password": "sha1$bc5c595c$1$d0e9fa434048a5ae1dfd23ea470ef2bb83628ed6"
}

そして、「id」または「email」のいずれかでドキュメントを照会できるようにしたいと考えています。したがって、これをビューとして保存するときは、次のように記述します。

db.save('_design/users', {
    byId: {
        map: function(doc) {
            if (doc.id && doc.email) {
                emit(doc.id, doc);
                emit(doc.email, doc);
            }
        }
    }
});

そして、次のようにクエリできます。

db.view('users/byId', {
    key: key
}, function(err, data) {
    if (err || data.length === 0) return def.reject(new Error('not found'));
    data = data[0] || {};
    data = data.value || {};

    self.attrs = _.clone(data);
    delete self.attrs._rev;
    delete self.attrs._id;

    def.resolve(data);
});

そして、それはうまく機能します。idまたはのいずれかでデータをロードできますemail。しかし、そうすべきかどうかはわかりません。

byIdとのような2つの異なるビューで同じドキュメントを保存する別の解決策がありますbyEmailが、この方法では同じドキュメントを2回保存すると、明らかにデータベースのスペースがかかります。

どちらのソリューションが優れているかはわかりません。

4

3 に答える 3

5

標準的な解決策は、2 つのビュー (1 つは電子メールによるビュー、もう 1 つは ID によるビュー) を持つことです。ドキュメントのスペースを無駄にしないために、値として null をinclude_docs=true発行し、ビューをクエリするときにクエリ パラメータを使用できます。

また、_idの代わりに使用することもできますid。こうすることで、CouchDB は ID が一意であることを保証し、ビューを使用してドキュメントをループする必要がなくなります。

于 2013-07-01T09:24:38.083 に答える
1

2 つの別々のビューに変更します。それは明確で明確です。同じドキュメントを 1 つのビューで 2 回発行すると、ID と電子メールによって、2 つのビューが効果的に 1 つに結合されます。ルート ブランチが 2 つある検索ツリーと考えることができます。それを行う理由がわかりません。データ アクセスとストレージの最適化ジョブをデータベースに任せることをお勧めします。

ビューの組み合わせは、何らかの理由で ID と電子メールを混同したときに、厄介なバグを引き起こす可能性もあります。

于 2013-07-01T07:11:23.240 に答える
1

異なるキーで同じドキュメントを複数回発行しても、まったく問題はありません。それは、アプリケーションにとって最も意味のあることです。

idとがユーザーを識別するための常に有効で交換可能な方法である場合email、単一のビューは完璧です。たとえば、idある種の一意のアカウント参照があり、ユーザーがその (覚えやすい) メールアドレスを使用してログインできる場合などです。

ただし、2 つの値を区別する必要がある場合 (たとえばid、アプリケーション管理者のみを対象とする場合) は、別のビューの方がよいでしょう。(代わりに複雑なキーを使用することもできますが、それは別の答えです。)

于 2013-07-01T10:15:08.480 に答える