2012-01-07 8 views
0

TutorとStudentの2つのモデルがあります。先生は、彼がカバーすることができる複数のトピックを持つことができ、学生は彼が学びたい複数のトピックを持つことができます。 10の可能なトピック(文字列内)があります。ルックアップテーブル、列挙型、またはRailsのキーから値を返す関数

トピック文字列を含むトピックテーブルを作成しようと考えています。しかし、それはこれらの文字列の不必要な繰り返しを作ります(テーブルを重くする)。だから私はトピックキーだけを含むトピックテーブルを作成します。

しかし、私は値を取得する方法について未定だ:

まず、私は、文字列値にキーをマップする、別のルックアップテーブルを作成することができます。これにより、余分なマージステップが発生します。

第2に、Topicに属し、valueから文字列を返すクラス関数を持つことができます。

どのように私の状況でより効率的でしょうか?私が考えていないより良いアプローチはありますか?

ありがとうございます。

+0

追加のフラグや役割の割り当て以外に、チューターとユーザーを区別する理由はありますか? – Nick

+0

はい、登録しています。しかし、私はこの文脈で、それは軽微な詳細だと思う。私は、教師と学生との多様な関係でトピックを実装することができます。 – AdamNYC

答えて

1

です。 IMOの「話題」は、管理が必要なもののように聞こえ、変わる可能性があります。

この場合、ID、名前、おそらく説明などを含むトピックテーブルが存在するはずです。チューターと学生の両方がhave_manyトピック:throughジョインテーブルになります。話題はbelong_toです。

トピックの多態的な関連付けを含むいくつかの実装オプションがあります。

+0

ありがとう、Dave。 topic-tableのアプローチがkey-valueをマッピングするクラス関数を持つよりも優れている理由を理解するのを助けてください。 IMOは、機能を変更することは同じように簡単にする必要がありますか? – AdamNYC

+0

@AdamNYC開発者にとっては、簡単です。そして、それが唯一の人なら、あなたは追加/編集/削除などができるようになりたいのです。トピック、罰金。私には人工的な制限のように思えます。 –

+0

ありがとう、Dave。あなたが正しいです。私はここでワンマンショップを超えて考える必要があります:) – AdamNYC

1

チューターモデルをロール割り当てを使用してユーザーモデルにロールインすると、ユーザーとトピックの間にhas_and_belongs_to_manyの関係が設定されます。これにより、より重い行を一緒に結合するために外部キーがリストされる結合表がセットアップされます。

class User < ActiveRecord::Base 
    has_and_belongs_to_many :topics 
end 

class Topic < ActiveRecord::Base 
    has_and_belongs_to_many :users 
end 

詳細については、Rails Guideを参照してください。

代わりに、has_manyアソシエーションを使用するだけですが、ジョインテーブルがないため、トピックごとのエントリを複製する必要があります。

+0

だからこそhas_many:throughがあります。 habtmに取って代わるものがあると言われる人もいますが、関連の上に追加のデータを入れないことが決まっていれば、habtmは私にとっては合理的です。私はそれに取り組んできたので、いくつかの議論があります。 –

+0

NickとDaveの両方に感謝します。私はhas_manyを使用すると思います:b/cを通して新しいトピックを追加する必要があるかもしれません。 – AdamNYC

関連する問題