2011-08-25 6 views
0

私が持っているテーブルDBスキーマの問題

  • USERS、
  • クラブ(id, creator_id, name, description
  • MONOPOLY(id, results
  • RISK(id, results, risk_specific_field

関係は次のとおりです。

  • USERS n:n CLUBS //私は
  • CLUBS 1:n MONOPOLY
  • CLUBS 1:n RISK

ユーザーが友人のクラブを作成して、別のゲーム(モノポリー、リスク)を再生するためにそのクラブに招待、それらの間の弱い実体をしています。

独占であれば、GameMonopolyテーブルの間に関係があるはずです。私はGames/MonopolyGames/Riskの間に弱いエンティティを作成すると思っていましたが、弱いエンティティがN:Nの関係を壊すためにこのアプローチが良いかどうか混乱します。これらは1:nです(1つのゲームはMonopolyテーブルN行にGameテーブルのMonopoly)。ゲームの唯一の種類は、私はid_monopoly私Gamesテーブルのフィールドを追加すると、それはそれだろうが、以来Monopolyだった場合も、このアプローチは、など私たちのアプリは、自分のテーブルでゲームの新しいタイプを追加する

を可能にします私のアプリはRiskも私はこのようにすることはできませんしています。

地獄は、私はここに私を懸念かについては明らかだった願っています:)

+0

@marc_sは - 編集 – luigi7up

答えて

0

私が正しく理解していれば、あなたが探していることはポリモーフィック団体です。代わりにちょうどid_monopolyを追加するので

、あなたはそれを一般化し、例えば2つの分野、追加します。

id_gametype_gameからid_gameがどちらかで独占するか、リスクへの「外部キー」とtype_gameは「どちらか独占です"または"リスク "。

ここでキャッチするのは、適切なテーブルのIDを調べるためにいくつかのアプリケーションロジックが必要になることです。これは複雑になる可能性がありますが、これがあなたのケースで役立つことを願っています。

+0

うんためのおかげで、あなたはそれが正しい:) だから、あなたは2つの外部キー... defenitelyに働くだろう。このアプローチを示唆しているだが、それは適切なソリューションですか?つまり、私はこのような事例を見たことがないので知らないでしょう:/ – luigi7up

+0

はい、これは一般的な解決策です。同じコンセプトを使用するレールガイドについては、http://guides.rubyonrails.org/association_basics.html#polymorphic-associationsを参照してください。必要なロジックのために頻繁には使用されないと思いますが、あなたが説明したようにセットアップ、これはそれを行う方法です。あなたがそれを制御することができれば、多型関連が必要でないという要件を変更することを検討することをお勧めします。 – Zaki

1

enter image description here