Results 1 to 2 of 2
Jan 29, 2006, 17:59 #1
- Join Date
- Sep 2004
- New York, NY
- 0 Post(s)
- 0 Thread(s)
[RoR] Table inheritence, or null columns?
I'm trying to decide what to do with a particular table relationships in RoR.
part of the current schema deals with hockey games being played between teams. so we're looking at: Game -> has many -> Teams
And the table games has a hometeam_id and awayteam_id foreign key to the teams table.
Now this schema is being expanded to account for a squash league as well. Squash is played between two players, not two teams. However, just about everything else is similar between the two: they both have a scheduled time to be played, a location, et cetera. And yes, many players participate in both. It seems to me that there are 3 options for dealing with this:
1) Ditch the games table completely, replacing it with a hockeygame and squashgame table, and just treating the two completely separately in code. This seems like the cleanest option, but perhaps the least efficient.
2) Add a is_team_game column into table games, as well as homeplayer_id and awayplayer_id as foreign keys to the players table. Then squash games will have null *team_id fields and hockey games will have null *player_id fields. This looks like a hack, but will allow me to treat both as "Game" in my code (for game in player.games <%= game.scheduled_time %> for all games of all types). This is what I would have done when I was a messy php programmer
3) Keep the games table, but also have hockeygame and squashgame tables, having the latter two inherit from the former, which deals solely with shared datatypes. This appears to be the architecturally correct solution, but I'm not sure how it manifests in rails code.
Jan 30, 2006, 06:26 #2
Option 3 would be nice but I'm pretty sure Rails doesn't support class table inheritance at this time. I do think it will arrive in due course though. See this ticket.
So, I would go for option 1. I wouldn't worry about efficiency at this stage...option 2 is just really smelly.