1

コメントが埋め込まれたリストドキュメントがあります。ビュー内のユーザーのコメントとともに、ユーザーの画面名とプロフィール写真を表示したいと思います。プロフィール写真が変更される可能性があり、画面名も変更される可能性があります。

私は、ここでの設計のベストプラクティスを特定しようとしています。Mongoを最大限に活用するには、埋め込まれたコメントは次のようになります。

コメントモデル

class Comment
  include Mongoid::Document
  field :user_id
  field :username
  field :profile_pic_url
  field :content
  field :created_at, type: Date
  embedded_in :list, :inverse_of => :comments
end

ただし、コメント内のすべてのインスタンスを更新するように見えるユーザーモデルにafter_saveフィルターがない限り、ユーザーがコメントデータ（ユーザーの画面名とプロファイル写真）を変更すると、コメントデータ（ユーザーの画面名とプロファイル写真）が古くなるリスクがあります。

適切な設計に関するガイダンスはありますか？コメントが埋め込まれないようにしたり、ユーザーのコメントが多く、リストのコメントが多いようにすることもできますが、モンゴの強みを生かそうとしています。

4

2 に答える 2

2

アプリケーション、アクセスパターン、スケーリング、およびパフォーマンス要件は、バックエンドの問題よりも優先されます。SQLでは、正規化とリンク/参照がほとんど唯一の選択肢ですが、MongoDBでは埋め込むことができます。

MongoDBは、スキーマをアプリケーションのニーズに一致させる柔軟性を提供し、必要に応じて正規化/リンク/参照または非正規化/埋め込みを選択できます。Mongoidを使用すると簡単に選択できます。

（a）正規化は、Do n't Repeat Yourself（DRY）の優れた原則に従って、冗長性を減らします。（b）非正規化は、パフォーマンスのためのキャッシュやメモ化などの一般的な方法に従って、冗長性を導入します。

一般に、アプリケーションのニーズに基づいて：

高い一貫性が必要-はい：正規化/リンク、いいえ：非正規化/埋め込み

高い読み取りパフォーマンスが必要です-はい：非正規化/埋め込み、いいえ：正規化/リンク

高い書き込みパフォーマンスが必要です-はい：正規化/リンク、いいえ：非正規化/埋め込み

高いスケーリングが必要-はい：正規化/リンク、いいえ：非正規化/埋め込み

関係：

1対1-はい：非正規化/埋め込み、いいえ：..。

1対多-はい：非正規化/埋め込み、いいえ：..。

多対多-はい：正規化/リンク、いいえ：..。

整合性を処理するためのさまざまな手法があります。たとえば、結果整合性のためのバックグラウンドまたは夜間のプロセス、即時整合性のためのルックアサイドキャッシュなどがあります。

悪いニュースは、考えを必要としない公式がないということです。幸いなことに、MongoDBにはアプリケーションに合わせた柔軟性があります。10genは、スキーマ設計に関する講演を提供しています。

于 2013-01-11T18:07:04.743 に答える
1

各コメントに各フィールドを入力する代わりに、ユーザーを参照します。

class User
  include Mongoid::Document
  include Mongoid::Timestamps
  field :user_id
  field :username
  field :profile_pic_url
  has_many :comments
end

class Comment
  include Mongoid::Document
  include Mongoid::Timestamps
  field :content
  belongs_to :user
  embedded_in :list, :inverse_of => :comments
end

has_manyリレーションのドキュメントは、 http：//mongoid.org/en/mongoid/docs/relations.html#has_manyにあります。

また、タイムスタンプを追加で使用し、 http： //mongoid.org/en/mongoid/docs/extras.html#timestampsに記載されているcreated_atフィールドを削除しました。

于 2013-01-09T22:22:22.720 に答える