4

MongoDBを学習していますが、データの重複について質問があります。SQLの世界では、データを正規化しようとします。たとえば、カテゴリのテーブルと製品のテーブルがあります。各製品は多くのカテゴリに属している可能性があるため、これらのテーブル間に結合があります。

しかし、MongoDBではこのように思わないのは正しいですか?代わりに、各製品にはカテゴリのドキュメントが埋め込まれていますか?それはまさにその通りですか?データが複製されてもかまいませんか?

4

1 に答える 1

7

SQLの世界では、データを正規化しようとします

常にではありませんが、死ぬまで正規化するとパフォーマンスが低下しますが、SQLと同じ正規化をMongoDBに個人的に適用しないのは事実です。

正規化された形式( http://en.wikipedia.org/wiki/Database_normalization )を知っている場合は、MongoDBを1NFに移行してから、再び非正規化に戻すと思います。

データが複製されてもかまいませんか?

そうそう、そうです。データが間違って複製された場合、更新は面倒です。

例を挙げましょう。categoryそして、product2つの別個のエンティティになるので、それを否定することはできません。これらの2つのエンティティは正規化されています(の繰り返しデータproductはからスピアリングされていますcategory)。別の考え方は次のとおりです。すべての製品は1つのカテゴリにのみ存在するのでしょうか。

したがって、トップレベルのエンティティでは、ご覧のとおり、同じルールが比較的適用され、1NFはMongoDBに簡単に適用されます。

もちろん、複製の前では、各カテゴリ内で各製品を個別に保存することは望まないので(上記の質問には「いいえ」と答えました)、当然、カテゴリと製品を分離する必要があります。

通常、ここでは、中間の正規化されたテーブルと多対多の関係があります。これが非正規化の出番です。カテゴリには、そのカテゴリに固有の製品のリストが含まれるため、多対多のリレーショナルテーブルをリストとしてカテゴリ行に非正規化できます。 (またはその逆で製品行に)。そのリストはそのカテゴリに固有であるため(おそらく)、これによって重複が生成されることはありません。もちろん、これは、カテゴリまたは製品が_id、オブジェクト自体ではなく、関連する行のリストを格納することを意味します。

主に最適化やJOINがない場合の回避策のために、複製が必要になる場合があります。このルールは、十分な規模のサイトを作成したことがある場合はSQLにも適用されます。

複製の一般的な使用シナリオは、Facebookの投稿の共有やコメントなどの統計の集計フィールドであり、おそらくその投稿の最新の5つのコメントも投稿行に複製されます。

したがって、これはスキーマ設計を無視する場合ではなく、MongoDBの特性に合わせてスキーマ設計を調整する場合です。通常、これを行うと、当然、優れたスキーマを設計することがわかります。

追加のリファレンスとして、ここで参照できます:http: //docs.mongodb.org/manual/core/data-modeling

于 2013-01-04T12:52:36.020 に答える