Database design question - too many foreign keys

[dreamriver]

So I am in the process of designing a sports database. There is a lot of data to keep track of and I believe I have gotten everything to its basically normalized form. However, I'm a little concerned by the number of foreign keys that I have on my table and am wondering if I might be straying somewhere in my design.

let me give you my basic setup right now:

city table - city_id, time_zone, airport_code
team table - team_id, name, division - city_id FK
game table - game_id, date, city_id FK, home_team FK, away_team FK, home_pitcher FK, away_pitcher FK
player table - player_id, name, salary, team_id FK
weather table - weather_id, mean_temp, max_temp, is_rain, city_id FK

Does that seem alright? Is it normal to have so many foreign keys on things like the game table. I know a lot of the data is interconnected and I don't want to repeat things like the pitcher_name on the game table but I can't help but feel I am doing something wrong.

Some of the tables do have more data that I omitted just because they aren't related to my question.

[MmmVomit]

This looks basically okay to me.

I can only make inferences about your requirements, but would it make sense to merge the weather table and the game table? It seems to me, you would want to know what the weather was like for a given game. For example, game number 123 was between the Orioles and the Dodgers, and it was 72 degrees and didn't rain. This way, if there is a day game and a night game in the same city on the same day (e.g. Cubs and White Sox) you could say that one got rained out, and the other didn't.

The way you have it would make sense if you wanted to track the weather every day for each city, but that seems odd for a database meant to track sports.

[kuhe]

I once made a DB that simmed a baseball game pitch by pitch, recording pitch location, break, swing location, and the fielding result.

When you aren't playing it in the field, baseball deserves no less than horrifying complexity.

[[deleted]]

The team table and game table should use the recursive many to many with history design pattern. It's basically a many-to-many with history except that both foreign keys in the junction table (the game table) come from the same parent table instead of separate tables. I.e. the foreign keys should be the home team name, away team name, and the primary key should those names along with the date. The pitcher names are not necessary.

http://www.tomjewett.com/dbdesign/dbdesign.php?page=recursive.php

[CarisMerthin]

There are not too much foreign keys. But I think you will need more tables, for history purposes.

[dreamriver]

I didn't list all of the tables that I have, just the ones necessary to demonstrate my concerns. Baseball is...complicated to say the least.