我目前正致力于为体育俱乐部开发应用程序,这使得俱乐部管理员可以管理各个部门,团队以及最终的球员。
目前我的数据库/关系如下
class Sport < ActiveRecord::Base
has_many :clubs
has_many :teams
attr_accessible :club_id
class Club < ActiveRecord::Base
belongs_to :sport
has_many :teams
has_many :users
has_many :divisions
attr_accessible :sport_id
class Division < ActiveRecord::Base
has_many :teams
belongs_to :club
attr_accessible :club_id
class Team < ActiveRecord::Base
has_many :users
has_many :schedules
belongs_to :division
belongs_to :club
attr_accessible :division_id, :club_id
class User < ActiveRecord::Base
belongs_to :club
belongs_to :team
attr_accessiable :club_id, :sport_id
我想要的是一种更简洁的管理方式。即。
目前上述情况正在发挥作用,但我不认为这种关系/结构处于最佳状态
答案 0 :(得分:1)
您所在的国家/地区只有单一的运动俱乐部?在德国,俱乐部的不同部门可以有不同的运动(我自己的俱乐部,例如田径,自行车,排球,篮球,桌上游泳和游泳)。在我的大部分应用程序中,我只是跳过了这项运动和各个部门:这项运动是从应用程序的背景中提供的,我认为俱乐部和部门是相同的。我的运动应用只是与俱乐部打交道,而不是俱乐部的分区。我认为这种牺牲是必要的,因为复杂性另外压倒了我 - 你的里程可能会有所不同,当然: - )
此外:用户只是暂时属于一个俱乐部,所以我在用户和团队之间有中间关系; &#34; Startberechtigung&#34;在德语中,像&#34; license&#34;用英语我会说;它属于team和belongs_to用户,并且有#34; start_date&#34;和&#34; stop_date&#34;作为附加属性。这样我甚至可以为俱乐部和用户提供历史记录。记录列表很重要(再次:田径)!
之后我会抛弃多余的传递关系:用户属于一个团队,而团队又属于俱乐部=&gt;使用has_many:通过更多;你不需要用户belongs_to俱乐部。
现在你的模特应该更清洁。
<强>更新强>:
不要使用classname&#34; User&#34;对于玩家来说,这最终会导致与您的用户/管理员模型发生冲突。 &#34;播放&#34;或者&#34;运动员&#34;对我来说没问题。
更新2 :
当然,你并不需要:通过每一种情况。包含或包含类方法的范围可能更适合您,尤其是。如果你想跨越多个中间阶段。
如何(请填写推荐指南中的漏洞):
class Sport < ActiveRecord::Base
has_many :clubs
has_many :teams, :through => :clubs, :readonly => false
class Club < ActiveRecord::Base
belongs_to :sport
has_many :teams
class Team < ActiveRecord::Base
belongs_to :club
has_many :athlete_teams
has_many :athletes, :through => :athlete_teams, :readonly => false
class AthleteTeam < ActiveRecord::Base
belongs_to :teams
belongs_to :athletes
class Athlet < ActiveRecord::Base
has_many :athlete_teams
has_many :athletes, :through :athlete_teams, :readonly => false
答案 1 :(得分:0)