Mongoid埋め込み可能なコメントと変更可能なユーザー情報

私は埋め込まれたコメントを持つリスト文書を持っています。ビューのユーザーのコメントに加えて、そのスクリーン名とプロフィール画像を表示したいと思います。プロフィール画像が変わる可能性があり、画面名も変わる可能性があります。

私は設計のためのベストプラクティスが何であるかを判断しようとしています。 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

ただし、コメントのすべてのインスタンスを更新するようなUserモデルにafter_saveフィルタがないかぎり、コメントデータ(ユーザーのスクリーン名とプロファイルピクチャ)は失効します。

適切な設計に関するガイダンスは?コメントは埋め込まれていないようにして、ユーザーにはコメントが多く、コメントには多くのコメントが付くようにすることができますが、私はMongoの強みに挑戦しています。

1
nl ru de

2 答え

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

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

(a)正規化は、自分自身を繰り返さない(DRY)という良い原則に従い、冗長性を減らします。 (b)非正規化は、パフォーマンスのためのキャッシングやメモのような一般的なプラクティスに従い、冗長性を導入する。

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

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

高い読み取りパフォーマンスが必要 - yes:denormalize/embed、no:normalize/link

高い書き込みパフォーマンスが必要 - yes:正規化/リンク、no:denormalize/embed

高スケーリングが必要 - yes:正規化/リンク、no:denormalize/embed

関係:

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

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

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

一貫性、例えば、最終的な一貫性のためのバックグラウンドまたは夜間のプロセス、即時の一貫性のためのルックアサイドキャッシュなどを処理するための様々な技術がある。

悪い知らせは、思考が必要ない式がないということです。良いニュースは、MongoDBがあなたのアプリケーションに適合する柔軟性を持っていることです。 10genはスキーマ設計に関する講演を行います。

2
追加された
私は最初の場所にコメントを埋め込むことで達成しようとしていたパフォーマンスプロファイルと最もよく一致しているため、コメントの一部としてユーザーの画面名と画像の両方を保存していました。
追加された 著者 aressidi,

私は各コメントに各フィールドを入れるのではなく、ユーザーを参照します。

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

You can find documentation for the has_many relation at http://mongoid.org/en/mongoid/docs/relations.html#has_many

また、タイムスタンプを余分に使用し、created_atフィールドを削除しました。これは http ://mongoid.org/en/mongoid/docs/extras.html#timestamps

1
追加された
ありがとうニコラス、これは仕事のための正しいアプローチのようです!
追加された 著者 aressidi,
私が気付いたことの一つ。私の期待は、私がコメントからユーザーモデルにアクセスできることでした。コメントはリストに埋め込まれているので、ルート文書(おそらくリスト文書)に余分な外部キーを格納する必要があるとMongoidは教えてくれます。私の見解では何をしようとしていたのですか? - @ comments.each do | c | %a.pull-left = image_tag c.user.profile.image:class => 'メディアオブジェクト' .media-body%h4.media-heading = c.username = c.content
追加された 著者 aressidi,