1

私がhas_many結合を持っていて、外部モデルにbelongs_toがない場合、結合が一方向である場合、実際には外部キーは必要ないことに気づきました。

に渡すことができるIDのマーシャリングされた配列を格納する列category_idsを持つことができますfind。

したがって、これはテストされていない例です。

class page < AR

  def categories
    Category.find(self.category_ids)
  end

  def categories<<(category)
    # get id and append to category_ids
    save!
  end

  def category_ids
    @cat_ids ||= Marshal.load(read_attribute(:category_ids)) rescue []
  end

  def category_ids=(ids)
    @cat_ids = ids
    write_attribute(:category_ids, ids)
  end

end

page.category_ids => [1,4,12,3]page.categories=>カテゴリの配列

これについてはすでに受け入れられているパターンはありますか？それは一般的ですか、それとも努力する価値がありませんか？

4

2 に答える 2

1

マーシャリング/アンマーシャリングを行うと、ここでパフォーマンスが低下しませんか？

個人的には、これは努力する価値がないと思いますし、あなたがやろうとしていることは明確ではないようです。

カテゴリが複数のページに属することを妨げるコードがないため、実際にはこれは多対1ではなく、多対多のマッピングのように見えます。確かに、次のようなものが必要です。

create table categories_pages (
  category_id integer not null references categories(id),
  page_id integer not null references pages(id),
  primary_key(category_id, page_id)
);

両側にhasとmanyに属しているか、両側にhas_many：throughがあります（より多くのものを保存するかどうかによって異なります）。

于 2009-06-02T20:10:11.500 に答える
1

私は、これは努力する価値がないように思われるというオマールに同意します。

データベースはデータモデルを反映しなくなり、この関係を強化するのに役立ちません。また、関係をhas_manyに制限する場合は、マーシャリングされたID配列をCategoryテーブルと同期させ、ページ全体で一意性を適用する必要があります。

しかし、最も重要なことは、このアプローチの利点は何だと思いますか？それは複雑さを増し、あなたが書かなければならないコードの量を増やすでしょう。

于 2009-11-24T21:13:28.327 に答える