2009-06-14 14 views
1

私は設計上の問題に遭遇しました。リーグ、選手、最初の2つの間の複数の接続(プレイヤーは、同時に2つ以上のリーグでプレーすることができますよう)に複数のマップ関連テーブルLeagueToPlayers:同じテーブル内のオブジェクト間の関係のマッピング

League  Players    LeagueToPlayers 
Id Name  Id Alias    LeagueId PlayerId 
=--------  ------------   ---------------- 
1 League A 1 Longcat   1  1 
2 League B 2 Leeroy Jenkins 1  2 
3 League C 3 xyz    2  1 
4 League D 4 qw3rty   2  3 
       5 Myrkgrav   3  2 
            4  1 
    (...)   (...)   4  3 
            5  1 

            (...) 

私のプロジェクトで、私は3つのテーブルを持っています問題は、プレイヤーの関係にプレーヤーをマッピングする必要があることです。 私の見解では、次の2つのことができます:追加のフィールドがPlayerテーブルに追加されるか(別のPlayerIdをマッピングする) - すべてのオッズでこれが1 .. *の関係になるか、テーブルが作成されます(実際にアイデアが大好きではありませんが、他の方法はありません)。

私はこの問題についてのあなたの見解を聞きたいと思います...明るいアイデアはありますか?

よろしく、ハル

EDIT:コメントで述べたように、これは比喩です。 "Player"テーブルに存在するオブジェクトのタイプはLOT(異なる200のタイプを考える)を変え、実際にはこのようにマップする必要があります。 Playerテーブル内のオブジェクトは、同じプロセスに参加するため、相互に関連しているため、相互に参照することができます。この接続は間違いなく1です。*

+0

これはプレイヤーとプレーヤーの関係の可能性はありますか? "とは対照的に"? 「スコアリングされた」? 「マンガー・オブ・」? 「同じようにランキングされましたか?関係には意味があります。意味は、これがどのように実装されるべきかを定義する。どういう意味ですか? –

+0

おかしい、それは通常、チームの選手とリーグのチームです。それがあなたがこの新しい要件で達成しようとしているものなら、私はあなたの命名規則に欠陥があると主張します。私は、Player-to-Teamでは1:m、Team-to-Leagueでは1:nを好むでしょう。 – duffymo

+0

リーグ対チームのために1:nであったはずです。私の間違い。 – duffymo

答えて

1

仮説的に行った後にDBを維持しなければならない場合は、の正規化の練習、一貫性とメンテナンスの簡素化のために、別の相関表をプレイヤーにマッピングすることを祈っています。

このソリューションは、モデルを拡張する理由が何であれ必要がある場合は、おそらくより優れた立場に立つという意味で、より柔軟性があります。

+0

Ahah :) ok、入力のためにありがとう –

+0

いつも喜び! – JohnIdol

1

1:*の場合は、*側に配置します(階層の子行のparent_idなど)。

*:*の場合は、別の相関表を使用します。

関連する問題