2

私は最近、空き時間に Couch DB でかなりの量の作業を行っており、それを使用することを本当に楽しんでいます。リレーショナル データベースを使用するよりもはるかに柔軟だと思いますが、欠点がないわけではありません。

大きな欠点の 1 つは、動的クエリ/ビュー生成の欠如です...そのため、SQL の場合のようにそのロジックをアプリケーション コードに入れることができないため、ビューの計画と正当化にかなりの量の作業を行う必要があります。 .

たとえば、次のような JSON ドキュメント テンプレートに基づいてログイン スキームを作成しました。

{ 
   "_id": "blah",
   "type": "user",
   "name": "Bob",
   "email": "bob@theaquarium.com",
   "password": "blah",
}

重複したアカウントの作成を防ぐために、キーとして検索するユーザー名のリストを生成する非常に基本的なビューを作成しました。

emit(doc.name, null)

これは私にはかなり効率的であるように思えました。ドキュメントのリスト全体 (または各ドキュメントのフィールド数を減らすだけ) をドラッグするよりもはるかに優れていると思います。そのため、まったく同じことを行って、電子メール アドレスのリストを生成しました。

emit(doc.email, null)

この質問で私がどこに向かっているのか分かりますか?

リレーショナル データベース (SQL を使用) では、同じテーブルに対して 2 つのクエリを作成するだけです。この手法 (ビューを SQL クエリの結果と同一視する) は、何らかの形で類似しているのでしょうか?

次に、パフォーマンス/効率の問題があります...これらの 2 つのビューは本当に 1 つにすぎないのでしょうか? または、キーがあり値が関連付けられていない Couch DB ビューを使用することは効果的な方法ですか? 上記の例を考えると、これらのビューはどちらもログイン スキームの外で使用されます... ユーザー名のリストを生成する必要がある場合は、追加のオーバーヘッドなしでそれらを取得できます。

どう思いますか？

4

1 に答える 1

1

まず、ビュー ロジックをアプリケーション コードに組み込むことができます。必要なのは、アプリケーションからビューを抽出して設計ドキュメントに追加する適切なビルド システムまたはデプロイ システムだけです。欠けているのは、その場で新しいクエリを生成する機能です。

あなたのemit(doc.field,null)アプローチは確かに驚くべきものでも珍しいものでもありません。実際、これは「フィールドでドキュメントを検索」クエリの通常のパターンであり、ドキュメントは を使用して抽出されinclude_docs=trueます。2 つのビューを 1 つに混在させる必要もありません。パフォーマンスに関連する唯一の決定事項は、2 つのビューを同じデザイン ドキュメントに配置するかどうかです。デザイン ドキュメント内のすべてのビューは、いずれかがアクセスされると更新されます。

もちろん、あなたのアプローチは、たとえあなたのアプリケーションが本当に懸命に努力したとしても、電子メールが一意であることを実際に保証するものではありません。2 つのクライアント アプリケーション A と B がある次の状況を想像してください。

A: queries view, determines that `test@email.com` does not exist.
B: queries view, determines that `test@email.com` does not exist.
A: creates account with `test@email.com`
B: creates account with `test@email.com`

これはめったに発生しませんが、可能性があります。より良い方法は、電子メール アドレスをキーとして使用するドキュメントを保持することです。これは、1 つのドキュメントへのアクセスがトランザクションに依存するためです (同じキーで 2 つのドキュメントを作成することは不可能です)。典型的な例:

{
  _id: "test@email.com",
  type: "email"
  user: "000000001"
}

{
  _id: "000000001",
  type: "user", 
  email: "test@email.com",
  firstname: "Test", 
  ...
}

編集: 予約パターンは、特定の電子メールのアカウントを作成しようとする 2 つのクライアントが同じドキュメントに確実にアクセスしようとする場合にのみ機能します。新しい識別子をランダムに生成すると、クライアント A はドキュメント XXXX を作成して予約し、クライアント B はドキュメント YYYY を作成して予約します。同じ電子メールを持つ 2 つの異なるドキュメントが作成されます。

繰り返しますが、トランザクションの「存在する場合はチェックし、存在しない場合は作成する」操作を実行する唯一の方法は、すべてのクライアントに1 つのドキュメントを変更させることです。

于 2012-01-30T12:18:47.673 に答える