Ok, Ok, I know I said that I was going to move into generating some of the reports and summaries that will be used in the public area. As I shifted perspectives from the material I discussed in the previous chapter into the broader context, however, I realized that I was first going to have to make some changes that I have known were coming for some time. Specifically, while the original structure of the participant_game table is fine for capturing the stream of events that take place in a game, it does little to put those events into context. What contextural information is there is only that which can be derived by viewing the events in the order defined by the event_order column. This is adequate in terms of reconstructing the game narrative, but leaves the determination of key baseball data (e.g., runs batted in) to an interpretation of that sequence. While some of this data could be extracted from the sequence with a sufficiently sophisticated query, such queries are resource-intensive and, if possible, it is a good idea to avoid creating situations that require them. Furthermore, some events, again such as RBIs, could not be inferred from that stream unless added as specific events. Therefore, I decided that it was time to bite the bullet and implement a more sophisticated structure.

As a result, however, I am also going to have to have to revamp the game entry process, and also the edit process for game records. The design of an entry process that can adequately record the details of a much richer record is itself somewhat challenging, and its implementation will take this document onto some new turf. Therefore, while I have postponed moving into some things, I have substituted others. <grin>.

Under this section, I will first discuss the new database structure for game records, then design and implement an interface capable of being used to efficiently record events into that structure.