自分のデータが本質的にリレーショナルまたはオブジェクト指向であることを知るにはどうすればよいですか？

これらの行を読むだけで

• データが本来オブジェクトである場合は、オブジェクトストア（「NoSQL」）を使用します。リレーショナルデータベースよりもはるかに高速です。

• データがリレーショナルデータである場合、リレーショナルデータベースのオーバーヘッドはそれだけの価値があります。

から-

http://seldo.com/weblog/2011/06/15/orm_is_an_antipattern

それで、データが本質的にリレーショナルであるかオブジェクト指向であるかをどのようにして知ることができますか？

撃ち落とされる危険を冒して、わかりやすい英語の定義を試してみます。

私にとっての「関係性」とは、特定のタイプのすべてのアイテムがほぼ同じ属性を持つため、単純なテーブルを設計するのは非常に簡単ですが、そのテーブルにすべてのアイテムを入れてから、CRUDと検索を実行するSQLです。さらに、すべてのアイテムが限られたタイプセットの1つを持つようにデータをモデル化できる場合、このタイプセットに対応するリレーショナルデータ構造を定義できます。

「オブジェクトの性質」は次のように変換されます。類似のタイプのアイテムにはさまざまな属性があり、これらの属性にはさまざまな性質とタイプがあります。多くの場合、これは（十分な労力をかけて）リレーショナルモデルに変換できますが、多くのテーブルは非常にまばらに配置され、非常に非効率的なLEFT OUTER結合になり、比較するとリレーショナルデータベースのパフォーマンスが遅くなりますNOSQLデータベースへ。

私の観点からは、これら2つを区別する厳密な線はありません。おそらく、この2つの両極端の間の任意の数の例を見つけることができます。

OK、だから私は今、あらゆる方向から狙撃兵に自分自身を開放しました。コメントを歓迎します。この定義を一緒に改善できるかどうか見てみましょう。

データは両方です。

（厳密に言えば、振る舞いが欠けているため、自然界ではオブジェクトになりえませんが、私たちは簡単には選びません）。

RDBMSまたはNoSQLデータベースへのデータの保存に関する決定は、データ自体の実際の「性質」というよりも、データの使用方法に大きく依存します。

データへのすべてのソートナビゲーションパスをサポートする場合は、データにアクセスして表示するさまざまな方法があるため、RDBMSにデータを格納することができます。多くの面倒な作業をデータベースで行う必要があります。たとえば、「注文」データには、顧客、営業担当者、SKU（アイテム）、日付、地域などを介してアクセスできます。

一方、最小限のナビゲーションパスがある場合は、オブジェクト全体を保存するだけでかまいません。たとえば、Webフロントエンドからのみアクセスされ、長期間保存されたり分析されたりしない「バスケット」は、NoSQLストアにより適しています。（ドキュメントまたはキー値）NoSQLデータストアを使用すると、コレクション間の関係なしで行うことが犠牲になります-これらの関係（ナビゲーションパス、アドホッククエリまたはレポート）が必要ない場合は、アプリ、あなたは大丈夫でしょう。

もちろん、さまざまな理由で両方にデータを保存できますが、それには欠点があります。

データは「自然のオブジェクト」でも「自然のリレーショナル」でもありません。リレーショナルまたはオブジェクトモデル/グラフ構造の両方で、あらゆる種類のデータを表現できます。適切なものは、アプリケーションがデータをどのように使用するかによって異なります。多くの場合、両方もあります。たとえば、Webサイトで使用されるデータはリレーショナルデータベースに格納できますが、オンデマンドでグラフ構造に読み込まれ、その後、メモリ内のキーと値のストアにキャッシュされます。

オブジェクトが格納するステートメント/ NoSqlは、ある種のデータに対してリレーショナルよりも高速になりますが、それは単に間違っています。ここでも重要なのは、データ自体の形式ではなく、アプリケーションがどのようにデータを使用するかです。オブジェクトストアは、1つの単位として格納されたオブジェクトグラフの読み込みは高速になりますが、多くのオブジェクトに対するアドホッククエリや、多くのオブジェクトのプロパティの更新は非常に遅くなります。

この記事の重要な点は次のとおりです。

"Likewise, sometimes the output will be a single object X, which is easy to represent. But sometimes the output will be a grid of aggregate data, or a single integer count"

あなたのコードが例えばスペインの顧客数を少しロジックを取得する場合など、スペインのすべての顧客で顧客のリストを作成してから数えるべきではないという点で著者は良い点を作っているようです顧客オブジェクト。（ORMがあなたを押しやるかもしれません）

顧客データ構造自体から、それがそのように使用されるかどうかを明らかにすることはできません。したがって、「アプリケーション」で使用されるすべての情報を意味する「データ」を解釈する必要があると思います。これに集約や「Yに関連するすべてのX」などのようなものが含まれている場合、「データ」はAtomic NoSqlアプローチには適していません