9

私は現在 Node.JS を学習しており、データベースを実装する必要があります。すべての Node 本は、MongoDB が最良の解決策であると考えているようですが、Mongo や Couch のような NoSql データベースについて理解できないようです。私は MS SQL Server 派です!

したがって、構造化データをレコード (JSON) として保持できることは理解していますが、次の (簡略化された) テーブルを使用して典型的な e コマース アプリをどのようにモデル化するかはわかりません...

customers (id, name, address)
orders (id, customerID, orderDate)
orderItems (id, orderID, productID)
products (id, title, description, image)

したがって、通常、このようなクエリを記述します (ただし、明らかに最適化された方が適切です)。

SELECT Customers.name, Products.title 
FROM (orders INNER JOIN customers ON orders.customerID = customers.id)
INNER JOIN orderItems ON orderItems.orderID = orders.id 
INNER JOIN products ON orderItems.productID = products.id

これが NoSQL データベースでどのように機能するかの例を見ることができれば、「理解」し始めるかもしれません。

あるいは、どちらも Node と互換性がある MSSQL Server または MySql を使用したほうがよいのでしょうか?

4

2 に答える 2

16

MongoDB のスキーマを設計する際の重要な考慮事項は、データが何であるかではなく、それをどのように使用するかです。どのタイプの読み取りと書き込みを行うか (およびそれらのパフォーマンスがどの程度になるか) を把握しないと、「最適な」スキーマを設計するのは難しい場合があります。

問題が発生しないように考慮できる基本的なガイドラインがいくつかあります。そのうちの 1 つは、際限なく拡大し続けるドキュメントを設計しないことです。つまり、注文を顧客ドキュメントに埋め込まないでください。もう 1 つのルールは、それ自体では "関心" がない (または単独では存在しない) ものは、おそらく埋め込んだほうがよいということです。これは、orderItems が独自のコレクションに値するものではなく、単純に注文の属性として扱われるべきであることを示唆しています (実際、これがそのようなものです)。

この正確な演習は、MongoDB 開発者トレーニングでカバーされており、スキーマ設計の非常に典型的な例です。

要するに、次の 3 つのコレクションが必要です。

商品
お客様
ご注文

注文は顧客を参照し (オプションで、顧客コレクションから一部の情報を非正規化)、製品を参照します (注文に含まれる orderItems の配列内)。

さらなるコレクション、およびこれらすべてのコレクションの正確なフィールドは、特定のユース ケースによって異なりますが、これら 3 つより少ないコレクションを持つ実行可能なシナリオは見当たりません。

于 2012-12-16T03:49:20.990 に答える
0

Mongo はコレクションを使用しますが、これは「テーブル」にある程度関連付けることができるため、ここに 4 つのコレクションを含めることができます。ただし、「注文」と「注文アイテム」を組み合わせて「注文」にすることができない理由はないことに注意してください。各エントリは、RDBMS で実現できるドキュメントに近いものになる可能性があることを考慮する必要があるからです。

書類を保管するだけのソファは違います。この場合、各ドキュメントにドキュメントの「タイプ」でフラグを立てることができます。次に、map/reduce を介して必要なデータを返すことができるビュー関数を作成できます。

これらのいずれについても、1 つのクエリですべてを実行することにあまりこだわらないでください。常に可能であるとは限りません。

ここでの重要なポイントは、SQL が統合子である RDBMS とは異なり、これに対する単一の「NoSQL」アプローチがないことです。NoSQL ストアの各 DB とタイプには長所と短所があり、どれが自分に最適かを判断する必要があります。

お役に立てれば。

于 2012-12-16T00:39:50.677 に答える