9

これについて話しているブログ投稿やドキュメントが見つかりません。埋め込みドキュメントとハッシュ データ型はどちらも非常に似ています。それぞれの利点または制限は何ですか?

私のスキーマ設計を考えてみましょう:

class HistoryTracker
  include ::Mongoid::Document
  include ::Mongoid::Timestamps

  field :modifier,          type: Hash,    default: {}
  field :original,          type: Hash,    default: {}
  field :modified,          type: Hash,    default: {}
  field :changeset,         type: Hash,    default: {}
end

この HistoryTracker クラス内にいくつかの埋め込みドキュメントを作成する必要がありますか? または単にそれを使用しますか？索引付けはどうですか？

4

3 に答える 3

7

Mongoid は、埋め込まれたドキュメントとハッシュ属性をデータベース レベルでほぼ同じ方法で保存します。mongoid を使用してモデル内のフィールドを宣言する場合は通常であるため、ネストされた構造がある場合は、埋め込みドキュメントを作成するのが通常です。MongoDB はスキーマレスであるため、mongoid は、ActiveRecord が行うのと同じ種類の API でフィールドを表示するために、フィールドを宣言する必要があります。ただし、一部のユース ケースでは、ハッシュ属性を使用すると柔軟性が向上します。この柔軟性の欠点は、Hash API に限定されているため、自動生成された属性メソッドを取得できず、モデル クラス内で通常行う方法でビジネス ロジックをカプセル化できないことです。

例として、多くの質問と回答のペアを含む多くのセクションを格納する必要があるアンケート モデルがあるとします。システムの重要な要件が、管理者が新しいセクションと質問を設定できるようにすることである場合、質問ごとに明示的なフィールドを含む通常の埋め込みドキュメントとして回答をモデル化することは容易ではありません。そのような場合、ハッシュの方が理にかなっているかもしれません。

特定の要件が何であるかはわかりませんが、大まかなガイドとして、埋め込みドキュメントを使用して固定スキーマスティックを使用している場合、制限のないモデルが必要な場合はハッシュ属性を検討してください。

于 2013-03-21T17:30:26.553 に答える
1

埋め込みドキュメントでは、次のように属性エイリアスもあります。

class Outer
  include Mongoid::Document

  embeds_one :inner_informative_object_with_long_name, store_as: :inn
end

class Embedded
  include Mongoid::Document

  attribute :vvla, as: :very_very_long_attribute, type: String
end

したがって、データベースには短い名前があり (使用されるメモリははるかに少なくなります)、コードでは長い名前を使用します。

于 2013-10-25T06:58:12.620 に答える