職場では、最近、CouchDB（ドキュメント指向データベース）を使用してプロジェクトを開始しました。私はリレーショナルデータベースの知識をすべて学ぶのに苦労してきました。
どうやってこの障害を乗り越えたのかしら？どのようにして関係的に考えるのをやめ、文書的に考え始めましたか（その言葉を作り上げたことをお詫びします）。
助言がありますか？役立つヒント？
編集：違いがある場合は、RubyとCouchPotatoを使用してデータベースに接続しています。
編集2：SOは答えを受け入れるために私を悩ませていました。私は私が最も学ぶのを助けたものを選んだと思います。しかし、本当の「正しい」答えはないと思います。
このテーマについて数ページを熟読した後、それはすべてあなたが扱っているデータの種類に依存すると思います。
RDBMSはトップダウンのアプローチを表しており、データベース設計者は、データベースに存在するすべてのデータの構造を表明します。個人には、名、姓、ミドルネーム、自宅の住所などがあることを定義します。これは、RDBMSを使用して適用できます。人のHomePlanetの列がない場合は、地球とは異なるHomePlanetを持っているPersonになりたいと思っています。後日、列を追加する必要があります。そうしないと、データをRDBMSに保存できません。ほとんどのプログラマーはとにかく自分のアプリでこのような仮定をしているので、これは仮定して強制するのは馬鹿げたことではありません。物事を定義することは良いことです。ただし、将来追加の属性をログに記録する必要がある場合は、それらを追加する必要があります。リレーションモデルは、データ属性があまり変更されないことを前提としています。
MapReduce（この場合はCouchDB）のようなものを使用する「クラウド」タイプのデータベースは、上記の仮定を行わず、代わりにボトムアップからデータを調べます。データはドキュメントに入力されます。ドキュメントには、さまざまな属性がいくつでも含まれている可能性があります。データは、その定義により、持つことができる属性のタイプが多様であると想定しています。「このドキュメントがデータベースPersonにあり、HomePlanet属性が「Eternium」でFirstNameが「LordNibbler」で、LastNameがないことを知っています。」このモデルはWebページに適合します。すべてのWebページはドキュメントですが、ドキュメントの実際のコンテンツ/タグ/キーは非常に大きく異なるため、DBMSが高い位置から認識している堅固な構造に適合させることはできません。これが、GoogleがMapReduceモデルのroxorssoxorsと考える理由です。■データセットは非常に多様であるため、最初からあいまいさを考慮して組み込む必要があります。また、大量のデータセットがあるため、並列処理を利用できます（MapReduceでは簡単です）。ドキュメントデータベースモデルは、データの属性が大幅に変更されるか、データがリレーショナルデータベースに保存されている場合に見られる「ギャップ」とまばらに入力された列が多数あるため、非常に多様であると想定しています。RDBMSを使用してこのようなデータを保存することはできますが、非常に高速になります。また、データがリレーショナルデータベースに格納されている場合に見つかる可能性のある、まばらに配置された列がたくさんあります。RDBMSを使用してこのようなデータを保存することはできますが、非常に高速になります。また、データがリレーショナルデータベースに格納されている場合に見つかる可能性のある、まばらに配置された列がたくさんあります。RDBMSを使用してこのようなデータを保存することはできますが、非常に高速になります。
あなたの質問に答えるには、MapReduceパラダイムを使用するデータベースを見るとき、「関係的に」考えることはできません。なぜなら、それは実際には強制された関係を持っていないからです。それはあなたがただ乗り越えなければならない概念的なこぶです。
2つのデータベースを非常によく比較対照する良い記事は、MapReduce：A Major Step Backです。これは、MapReduceパラダイムデータベースは技術的な後退であり、RDBMSより劣っていると主張しています。私は著者の論文に反対しなければならず、データベース設計者は自分の状況に合ったものを選択するだけでよいと主張します。
それはすべてデータに関するものです。関係的に最も意味のあるデータがある場合、ドキュメントストアは役に立たない可能性があります。典型的なドキュメントベースのシステムは検索サーバーであり、膨大なデータセットがあり、特定のアイテム/ドキュメントを検索したい場合、ドキュメントは静的であるか、バージョン管理されています。
アーカイブタイプの状況では、ドキュメントは文字通り変更されず、非常に柔軟な構造を持つドキュメントである可能性があります。メタデータをリレーショナルデータベースに保存することは意味がありません。メタデータはすべて非常に異なり、それらのタグを共有するドキュメントはほとんどないためです。ドキュメントベースのシステムはnull値を保存しません。
非リレーショナル/ドキュメントのようなデータは、非正規化されたときに意味があります。それはあまり変わらないか、一貫性についてはあまり気にしません。
ユースケースがリレーショナルモデルにうまく適合している場合は、それをドキュメントモデルに詰め込む価値はないでしょう。
これは、非リレーショナルデータベースに関する優れた記事です。
別の考え方として、ドキュメントは行です。ドキュメントに関するすべてがその行にあり、そのドキュメントに固有です。行は簡単に分割できるため、スケーリングが簡単です。
Lotus Notesのように、CouchDBでは、ドキュメントを行に類似していると考えるべきではありません。
代わりに、ドキュメントはリレーション（テーブル）です。
各ドキュメントにはいくつかの行があります-フィールド値：
ValueID(PK) Document ID(FK) Field Name Field Value
========================================================
92834756293 MyDocument First Name Richard
92834756294 MyDocument States Lived In TX
92834756295 MyDocument States Lived In KY
各ビューは、すべてのドキュメントの大規模なUNIONALLを選択するクロス集計クエリです。
したがって、それはまだリレーショナルですが、最も直感的な意味ではなく、最も重要な意味ではありません。優れたデータ管理手法です。
ドキュメント指向データベースは、リレーションの概念を拒否しません。アプリケーションがリンクを逆参照したり（CouchDB）、ドキュメント間のリレーションを直接サポートしたりする（MongoDB）場合もあります。さらに重要なのは、DODBがスキーマレスであることです。テーブルベースのストレージでは、このプロパティはかなりのオーバーヘッドで実現できますが（richardtallentによる回答を参照）、ここではより効率的に実行されます。RDBMSからDODBに切り替えるときに本当に学ぶべきことは、テーブルを忘れてデータについて考え始めることです。これが、sheepsimulatorが「ボトムアップ」アプローチと呼んでいるものです。これは進化し続けるスキーマであり、事前定義されたプロクラステスのベッドではありません。もちろん、これはスキーマが何らかの形で完全に放棄されるべきであることを意味するものではありません。アプリケーションはデータを解釈する必要があり、
このhttp://books.couchdb.org/relax/getting-startedを読む必要があるかもしれません
私自身はそれを聞いたばかりで興味深いですが、実際のアプリケーションでそれを実装する方法がわかりません;）
試すことができることの1つは、firefoxとfirebugのコピーを取得し、マップを操作してjavascriptの関数を減らすことです。それらは実際には非常にクールで楽しいものであり、CouchDBで物事を成し遂げる方法の基礎になっているようです。
これは、このテーマに関するJoelの小さな記事です：http：//www.joelonsoftware.com/items/2006/08/01.html