Loading ...
Sorry, an error occurred while loading the content.

3715Re: [baseball-databank] Fixing Bat Hand Code

Expand Messages
  • Michael Westbay
    Jan 5, 2009
    • 0 Attachment
      I've always dealt with this problem by having a Stint table containing
      anything that *may* change in a given stint/season.

      PlayerID integer(11)
      Season integer(4)
      Stint integer(2)
      Team varchar(5)
      Throws enum('R','L')
      Bats enum('R','L','B')
      Height integer(3)
      Weight integer(3)
      UniNo integer(3)
      UniHead varchar(1) default '' -- To handle 00
      PrimePos enum('P','C','1B','2B','3B','SS','LF','CF','RF','IF','OF','DH','PH','PR')

      Those are the definitions I can think of off the top of my head. I
      know that Throws rarely, if ever, changes. It's just a tag along to
      accompany similar data (and to handle the extremely remote possibility
      should it ever occur). I used to have salary information in there,
      but eventually moved it to its own table.

      My guess that the reason so many databases put the above information
      in the Master table is because they started off just concerned about
      the *current* season - then didn't refactor when the next season came
      along and the above information only changed for a hand full of
      players.

      (I use the UniHead field like so: SELECT ... CONCAT(UniHead,UniNo) AS
      No ... ORDER BY UniNo, ... to handle those instances where a team has
      someone with 00 and still be able to sort by uniform number as a
      number, not as a string.)

      I've also experimented with holding these values in an Attributes
      table using starting and ending dates, but that causes all kinds of
      convoluted SQL queries to be made just to show all of the current
      attributes.

      --
      Michael Westbay
      Writer/System Administrator
      http://www.japanesebaseball.com/
    • Show all 13 messages in this topic