I don't know how sophisticated you plan for your sim to be, but the
inferred series method can fall down if you use a schedule generator
that creates a more "real-world" schedule where series can be spread
over two weeks, or where there are make up games (that could get
wrapped into a series if it takes place in the same week as another
series, even if there are games for one of the two teams in between
the makeup and original series), etc.

>From the top down, I found this to be a decent league scheduling model
for series-based sports (assuming you have multiple leagues, years,
etc):

schedule
  id
  league_id
  year_id

series
  id
  schedule_id
  scheduled_start_date
  scheduled_end_date

game
  id
  schedule_id
  series_id
  park_id
  scheduled_date
  played_date
  running_time
  home_team_id
  away_team_id
  winner_team_id
  winner_score
  loser_team_id
  loser_score
  etc


That might be more complicated than you want, but it would handle odd
schedules (games overlapping weeks, rain-out reschedules, etc). And
then you could paginate based on the Series model (and you could also
run stats more easily on series). You do have data duplicated in the
Series and Game tables (schedule_id), but thats because Series is
designed to be a convenience table - for most queries (seasonal
record, for example) you'd be able to bypass it completely, but for
display or Series aggregate reporting (winning series, score per
series, etc) you could use it. You don't necessarily need it in your
table chain from league -> schedule -> game.


Two more random, unsolicited notes:

IME, doing winner_team_id/winner_score vs. home_score makes it a lot
easier to run various queries later for reporting records and
correlating stats to wins/losses.

Also, I'd probably put park_id in the series and/or game tables,
assuming you're tracking parks - and applying park effects. :)  While
it could be inferred from the team record of the home_team_id and
would usually be right, games are occasionally played at stadiums
other than the home team's park. Again, depends on the complexity you
want to support.


Out of curiosity, have you looked at the Lahman database and/or
retrosheet.org?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Cake 
PHP" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/cake-php?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to