As a general rule, if you ever realize that you have a lousy table design, the correct thing to do is always to correct it now, instead of in the future. Otherwise you will be banging your head against a brick wall several times over, and might still end up having to do the redesign later on...
Things will of course get more complicated if you have live data, but you can always create new tables while the old design still exists, then move existing data into the new tables, switch your code to start using these instead, and finally drop the old tables.
Anyway, my thoughts on the subject. First off, I'd recommend only using backticks `to quote identifiers if the identifier in question is a reserved word (such as "date" or "table"), to make things more readable. But, it's of course nothing but a personal preference. I'm certain some people prefer always having them so as not to accidentally miss a reserved word identifier.
Lets look at your current table
games_id INT(20) NOT NULL AUTO_INCREMENT,
That line should end in PRIMARY KEY (unless you specify that after the column definitions and simply didn't paste that part of the code).
week VARCHAR(7) NULL DEFAULT NULL,
year YEAR(4) NULL DEFAULT '2011',
I'd much rather store these, and anything else regarding dates and times as one single date time field, since you can always use DATE_FORMAT(gamedate, '%v') to get the date's week number. There are also three more ways of numbering weeks: %U, %u and %V, so make sure you use whichever matches your expectations of what day starts a week and where week numbering starts.
home_owner_id INT(2) NULL DEFAULT NULL,
home_team VARCHAR(50) NULL DEFAULT NULL,
Team data should be stored in a team table, and you should never store redundant data. That is, if the team name is in the team table (it should be), then you will not have it anywhere else. Well, that is unless the team name is actually the team table's primary key in which case you'd have the team name in the game table. However, if that was the case, you'd have no team_id. See Database Normalization for more info on the subject. It's a good read for how to design your DB schema.
home_team_win INT(1) NULL DEFAULT '0' COMMENT '1 = game winner',
home_team_loss INT(1) NULL DEFAULT '0' COMMENT '1 = game loser',
Here you also have redundant data. If home team wins, home_team_win will be 1. But that 1 means they didn't lose, so I allready know that home_team_loss is 0. And not only these two are involved, but then you have another two fields that are allready redundant due to home_team_win, namely away_team_win and away_team_loss (if home_team_win = 1, then away_team_win is 0 and ..._loss is 1).
But, you also store home_team_score and away_team_score, which makes even home_team_win redundant. The scores of the two teams allready store data about who won and who lost.
Also note that if a draw is possible, i.e. noone wins and noone loses, then the game scores would also be able to indicate this, whereas setting win and loss to 1 and 1 or setting them to 0 and 0 could lead to logical errors. If you simply count how many games a team won by SUM(win) and how many times they lost by SUM(loss), a draw would give them credits for both one win and one loss while it actually was neither.
With comments on the current structure out of the way, I'd probably go with this
TABLE games (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
home INT UNSIGNEDm
gamedate DATE, -- or DATETIME if you want to keep track of time as well
-- more easily handled than bit-type fields such as playoff: 1/0, superbowl: 1/0
-- and also doesn't require any comments.
gametype ENUM('normal', 'playoff', 'superbowl'),
FOREIGN KEY (home) REFERENCES teams(id)
);
TABLE teams (
id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
teamname VARCHAR(30)
);
TABLE team_games (
team_id INT UNSIGNED,
game_id INT UNSIGNED,
score TINYINT UNSIGNED,
PRIMARY KEY (team_id, game_id)
FOREIGN KEY (team_id) REFERENCES teams(id),
FOREIGN KEY (games_id) REFERENCES games(id)
);
