Should a two-to-many data relationship be treated as many-to-many?

Question

I have 2 database tables: Teams and Games.

For the purpose of this question, we are dealing with football (soccer) teams and games.

Each Game has exactly 2 teams, generally a home team and an away team although occasionally both teams can be neutral.

My question is whether I should represent this data relationship using 2 foreign keys in the Games table (home_team_id, away_team_id) or whether I should use a many-to-many relationship with a games_teams table to link the two, in which case I would need to also store whether the team was the home or away team and seems a little overkill.

To add to the confusion, I am using the ORM libs in KohanaPHP and these would expect an fk to be called team_id or a link table to contain only 2 columns. If you have experience with this problem in KohanaPHP then please leave a reply, else any general advice is also much appreciated.

Answer 1

If you want to be able to pin a "Xth Normal Form" badge on your database server, then it should probably be treated as many-to-many, otherwise, I should think you'll reduce your query overheads with 1 fewer table that you're just going to join through every time you want some useful data out.

Answer 2

Just use the two columns, otherwise you'd just need to qualify it in the joiner table. It's not as if this is a sleeping time bomb and suddenly one day you'll discover you need to have a real many to many.

Answer 3

2 columns is perfectly appropriate here in my opinion. The fact that there can only possibly be two teams for any game is reflected in your database schema by having two columns. By introducing a linking table, you introduce the possibility that a single game could have 2 home teams, 2 away teams, and you would need additional validation to ensure that this scenario never occurs. By keeping things isolated to the two columns, your schema inherently enforces data integrity.

Answer 4

In terms of normalization: Yes. There is only a one-to-many or a many-to-many that gets broken down into one or more one-to-many relationships.

But realistically speaking, if I were to save something like GENDER. Would I really need a multi-state and a datetime stamp attached to this?

The surprising answer is YES - but only if I need to track gender changes for business reasons - for most practical purposes the answer is NO.

I would keep one table with two keys - unless there is a business reason to track it as such.

Normalize until it hurts, denormalize until it works. :)

Answer 5

Depending on how you have abstracted it, I would say that soccer game MUST have two teams, in which case having the columns in the Game table is not only more convenient, it's more correct.

I could even imagine the team id's being natural parts of the primary key of Game.

Answer 6

Totally think you should NOT have a separate table for this. Easier on the programmer, easier on the DB. Good to think about the what ifs, but sounds like you already have. Don't get caught thinking that normalization is always the way to go for everything.

Answer 7

Two columns would be best.

Answer 8

In my opinion, these are two one-to-many relationships, so you should be fine.

Answer 9

I respect the answers of the other in saying that using the two columns is the best choice, however, you mention that you are using the ORM library in Kohana. By using two columns in the games table you lose the ORM features for many-to-many relationships. If you set up a games_teams pivot table, you can do the following:

$game = ORM::factory('game', 1); // 1 is the game id

Then you can loop through the teams in that game:

foreach ($game->teams as $team) {
// do stuff with $team
}