0

次の Mongoid モデルを検討してください

class Doc
  include Mongoid::Document
  field :name, type: String
  embeds_many :images
  embeds_many :videos
end

class Image
  include Mongoid::Document
  field :url, type: String
  field :caption, type: String
  embedded_in :Doc
end

class Video
  include Mongoid::Document
  field :url, type: String
  field :caption, type: String
  embedded_in :Doc
end

このモデルに対して

class Doc
  include Mongoid::Document
  field :name, type: String
  embeds_many :images
  embeds_many :videos
end

class Image
  include Mongoid::Document
  embeds_many :urls
  embeds_many :captions
  embedded_in :Doc
end

class Video
  include Mongoid::Document
  embeds_many :urls
  embeds_many :captions
  embedded_in :Doc
end

class Url
  include Mongoid::Document
  embedded_in :image
  embedded_in :video
  field :url, type: String
end

class Caption
  include Mongoid::Document
  embedded_in :image
  embedded_in :video
  field :caption, type: String
end

各モデルの利点は何ですか?

簡潔にするために最初のものを使用する必要がありますか、それとも後でクエリをより細かく制御できるように url.url ポイントに原子化する必要がありますか?

4

1 に答える 1

0

最初のモデルでは、1 つの URL を各画像または動画に関連付けることができます。2 番目のモデルでは、多くの URL を各画像またはビデオに関連付けることができます。

ビジネス要件に適しているのはどれですか? 画像に多くの URL を含めることは可能ですか? それとも 1 つしかありませんか?

個人的には、特定の画像に対して厳密に多くの URL が必要でない限り、最初のモデルを使用します。Web 上の各メディアの URL は一意であることがほぼ保証されているため、データ構造を過度に正規化しても意味がありません。URL クラスには、Video レコードと Image レコードを合わせた合計と同じ数のレコードがあるため、何を節約しますか?

一意ではない値を持つ可能性のある他の文字列フィールド (たとえば、タグ) である場合は、イメージとビデオのレコードよりもタグ モデルのレコードが劇的に少なくなるため、それを分割することは非常に理にかなっています。高度またはタグの再利用。

わかる？

于 2012-04-24T19:47:17.140 に答える