The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

[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.