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

RE: [baseball-databank] Digest Number 392

Expand Messages
  • KJOK
    Tom: True, but my point is if these records are not also in their own child table (No play table?) or if there s not some indicator on the master record to
    Message 1 of 13 , Dec 4, 2003
      Tom:
       
      True, but my point is if these records are not also in their own "child" table (No play table?) or if there's not some indicator on the master record to indicate these are master records with no child table records, then there would be no way to know why these records were even in the master table.
       
      THANKS,
      Kevin

      "tmasc@..." <tmasc@...> wrote:

      --- KJOK <kjokbaseball@...> wrote:
      > Tom:

      > Yes, but if they just had a master table with NO
      > links to any data in any other table, I don't think
      > that would be correct either?

      > I guess once we had a "transactions" table, they
      > would at least have 1 entry there?

      > THANKS,
      > Kevin
      >

      The MASTER table, once we get done with the redesign,
      will include umpires, Japanese players, Negro
      leaguers, managers, minor leaguers, etc.  The MASTER
      table, by itself, will not be useful to establish if a
      player ever played in a MLB game.

      Let me stress that the new eventual design of the DB
      has a target audience of DB developers.  Therefore, it
      would be up to the "middle man", like Sean Lahman,
      Sean Forman and others, to produce a database or
      report or whatever that the end user will appreciate.
      From that standpoint, they may choose to ONLY include
      players who played at least 1 game in MLB.

      Tom

      __________________________________
      Do you Yahoo!?
      Protect your identity with Yahoo! Mail AddressGuard
      http://antispam.yahoo.com/whatsnewfree


      http://www.baseball-databank.org/

      To unsubscribe from this group, send an email to:
      baseball-databank-unsubscribe@yahoogroups.com



      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


      Do you Yahoo!?
      Free Pop-Up Blocker - Get it now

    • jagbbg
      Probably the best way to handle this would be to include some type of flag field, say an 8-bit or 16-bit one would probably do it. That way, you can have a
      Message 2 of 13 , Dec 4, 2003
        Probably the best way to handle this would be to include some type of
        flag field, say an 8-bit or 16-bit one would probably do it. That
        way, you can have a master table that acts as a who's who of the
        sport of baseball, with an indicator of what their relationship to
        the game is. For the non-tech heads, which I myself am by no means,
        basically you decide on who you are going to include and assign them
        a number. For example:

        1 - MLB Player
        2 - Minor League Player
        3 - MLB Umpire
        4 - MLB Manager
        5 - Minor League Manager
        6 - Japanese League Player
        7 - Cuban League Player
        8 - Baseball Hall Of Fame Season Pass Holder
        etc., etc., etc.

        Then, you can use a binary flag to indicate who they are. So, if a
        person was once a minor leaguer, a MLB player, and a manager, then
        the entry in the flag field would look like this (using the eight
        possibilities above):

        11010000

        That way, you have established HOW and WHY an individual is included
        in the Master table. Then, you can leave it to the DB programmers to
        create the relationships to other tables based on the information in
        the flag field.

        John G.


        --- In baseball-databank@yahoogroups.com, KJOK <kjokbaseball@y...>
        wrote:
        > Tom:
        >
        > True, but my point is if these records are not also in their
        own "child" table (No play table?) or if there's not some indicator
        on the master record to indicate these are master records with no
        child table records, then there would be no way to know why these
        records were even in the master table.
        >
        > THANKS,
        > Kevin
        >
        > "tmasc@y..." <tmasc@y...> wrote:
        >
        > --- KJOK <kjokbaseball@y...> wrote:
        > > Tom:
        > >
        > > Yes, but if they just had a master table with NO
        > > links to any data in any other table, I don't think
        > > that would be correct either?
        > >
        > > I guess once we had a "transactions" table, they
        > > would at least have 1 entry there?
        > >
        > > THANKS,
        > > Kevin
        > >
        >
        > The MASTER table, once we get done with the redesign,
        > will include umpires, Japanese players, Negro
        > leaguers, managers, minor leaguers, etc. The MASTER
        > table, by itself, will not be useful to establish if a
        > player ever played in a MLB game.
        >
        > Let me stress that the new eventual design of the DB
        > has a target audience of DB developers. Therefore, it
        > would be up to the "middle man", like Sean Lahman,
        > Sean Forman and others, to produce a database or
        > report or whatever that the end user will appreciate.
        > From that standpoint, they may choose to ONLY include
        > players who played at least 1 game in MLB.
        >
        > Tom
        >
        > __________________________________
        > Do you Yahoo!?
        > Protect your identity with Yahoo! Mail AddressGuard
        > http://antispam.yahoo.com/whatsnewfree
        >
        > Yahoo! Groups SponsorADVERTISEMENT
        >
        > http://www.baseball-databank.org/
        >
        > To unsubscribe from this group, send an email to:
        > baseball-databank-unsubscribe@yahoogroups.com
        >
        >
        >
        > Your use of Yahoo! Groups is subject to the Yahoo! Terms of
        Service.
        >
        >
        > ---------------------------------
        > Do you Yahoo!?
        > Free Pop-Up Blocker - Get it now
      • Michael Westbay
        ... Hash: SHA1 ... I think a problem is calling the table with people in it the Master table. That infers that it s the starting point for looking up people
        Message 3 of 13 , Dec 4, 2003
          -----BEGIN PGP SIGNED MESSAGE-----
          Hash: SHA1

          KJOK wrote:

          > True, but my point is if these records are not also in
          > their own "child" table (No play table?) or if there's not some
          > indicator on the master record to indicate these are master records
          > with no child table records, then there would be no way to know why
          > these records were even in the master table.

          I think a problem is calling the table with people in it the Master
          table. That infers that it's the starting point for looking up people
          and what they do. I plan on renaming it to the People table, containing
          only information unique to a given person such as place/date of
          birth/death, name, etc. What they do/did doesn't belong there.

          A Players table will reference the People table and Teams table to
          connect the two. An Umpires table will connect with the People table
          and Leagues table to state what league an umpire works/worked for.
          Salaries, as pointed out by Tom, link a person with a salary for a given
          year. (Still need to work on how to figure out what organization the
          person belonged to for that year.)

          In short, it's not the "Master" table that one goes to, it's the various
          tables that describe a particular job that the person does: ball player,
          umpire, writer, statistician, owner, etc. Because many of these overlap
          (ball player turned manager or writer), only one entry in the People
          table is necessary. If he had a salary as a player for any covered team
          for a given year, then he'll need to be in the Salaries table, thus a
          link to an entry in the People (Master) table is necessary. That's what
          Tom is saying. The over-all data being stored is more than plate
          appearances and/or outs pitched.

          - --
          Michael Westbay
          Writer/System Administrator
          http://JapaneseBaseball.com
          Public Key: http://www.japanesebaseball.com/keys/westbaystars.gpgkey
          -----BEGIN PGP SIGNATURE-----
          Version: GnuPG v1.2.2 (Darwin)
          Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

          iD8DBQE/0CsmEGkvdz3fJlcRAghnAKCJolRKOwaPopc7dAyG9MDraTqBXgCgwS76
          TYHwXV/IjPfZjbtAbYLbDYg=
          =bCzz
          -----END PGP SIGNATURE-----
        • tmasc@yahoo.com
          ... Hmmmm.... so, you are talking about a record in the master table that has no children record, and now we don t know why he s even in the master table (a
          Message 4 of 13 , Dec 5, 2003
            --- KJOK <kjokbaseball@...> wrote:
            > Tom:
            >
            > True, but my point is if these records are not also
            > in their own "child" table (No play table?) or if
            > there's not some indicator on the master record to
            > indicate these are master records with no child
            > table records, then there would be no way to know
            > why these records were even in the master table.
            >
            > THANKS,
            > Kevin
            >

            Hmmmm.... so, you are talking about a record in the
            master table that has no children record, and now we
            don't know why he's even in the master table (a player
            who never played in MLB? or in Japan? or he was on
            the post-season roster, and not regular season
            roster?)

            Seems to me then we need a 25-man roster or 40-man
            roster table. Either that, or we create another table
            of "on roster, but did not play".

            Great catch!

            Tom



            __________________________________
            Do you Yahoo!?
            Protect your identity with Yahoo! Mail AddressGuard
            http://antispam.yahoo.com/whatsnewfree
          • KJOK
            Yep, you interpreted what I meant to say! I think need a roster table that would have Team, League and then indicators for 40-man, 25-man, Div Series, LCS,
            Message 5 of 13 , Dec 5, 2003
              Yep, you interpreted what I meant to say!  I think need a "roster" table that would have Team, League and then indicators for 40-man, 25-man, Div Series, LCS, World Series, etc.

              "tmasc@..." <tmasc@...> wrote:

              --- KJOK <kjokbaseball@...> wrote:
              > Tom:

              > True, but my point is if these records are not also
              > in their own "child" table (No play table?) or if
              > there's not some indicator on the master record to
              > indicate these are master records with no child
              > table records, then there would be no way to know
              > why these records were even in the master table.

              > THANKS,
              > Kevin
              >

              Hmmmm.... so, you are talking about a record in the
              master table that has no children record, and now we
              don't know why he's even in the master table (a player
              who never played in MLB?  or in Japan? or he was on
              the post-season roster, and not regular season
              roster?)

              Seems to me then we need a 25-man roster or 40-man
              roster table.  Either that, or we create another table
              of "on roster, but did not play".

              Great catch!

              Tom



              __________________________________
              Do you Yahoo!?
              Protect your identity with Yahoo! Mail AddressGuard
              http://antispam.yahoo.com/whatsnewfree


              http://www.baseball-databank.org/

              To unsubscribe from this group, send an email to:
              baseball-databank-unsubscribe@yahoogroups.com



              Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.


              Do you Yahoo!?
              Free Pop-Up Blocker - Get it now
            • tmasc@yahoo.com
              ... For the database that would be produced by the any number of DB developers for the end-user, that s fine. (In fact, ANYTHING is fine here. There are no
              Message 6 of 13 , Dec 5, 2003
                --- jagbbg <jagbbg@...> wrote:
                > Probably the best way to handle this would be to
                > include some type of
                > flag field, say an 8-bit or 16-bit one would
                > probably do it. That
                > way, you can have a master table that acts as a
                > who's who of the
                > sport of baseball, with an indicator of what their
                > relationship to
                > the game is.

                For the database that would be produced by the any
                number of DB developers for the end-user, that's fine.
                (In fact, ANYTHING is fine here. There are no
                rules.)

                For the database that would be produced by the one BDB
                DB admin for the DB developer (i.e., the core 3NF
                database) this would not be fine. You can't have a
                field in one table that can be explained by a field in
                another table.

                In this case, we can create an optional flag that
                explains why we have a record in the MASTER table that
                has no other record in any of the other tables. But,
                associated to this would be other information, like
                dates.

                So, you would want to know that he was part of the
                post-season roster for NYA, 1960, etc, etc. This is
                why I would think that we would end up with a ROSTER
                table to handle this. The ROSTER table would be a
                parent to the various batting, pitching, fielding, etc
                tables.

                Tom



                __________________________________
                Do you Yahoo!?
                Protect your identity with Yahoo! Mail AddressGuard
                http://antispam.yahoo.com/whatsnewfree
              • tmasc@yahoo.com
                On the question of salary, this too should be rethought. Manny Ramirez may have signed a 8-yr 160 million$ contract, but that doesn t mean he s making 20
                Message 7 of 13 , Dec 6, 2003
                  On the question of salary, this too should be
                  rethought. Manny Ramirez may have signed a 8-yr 160
                  million$ contract, but that doesn't mean he's making
                  20 million$ / year.

                  (For those who don't follow Present Value, if you win
                  the lottery, and we offered 10 million$ now, or 1
                  million$ per year for 11 years, what would you do?)

                  In terms of data recording, the contract should be
                  recorded as whatever it is. So, what you first need
                  is a CONTRACT table, that shows what the payouts are
                  supposed to be, including bonuses etc.

                  How someone wants to interpret this in terms of luxury
                  tax purposes, or what happens with Mondesi being
                  traded mid-contract, and salaries being covered, etc,
                  is another issue.

                  The SALARY table is a little misleading because it
                  interprets the data in a way that others would
                  dispute.

                  In any case, there's probably not much for us to do
                  about it at this point.

                  Tom

                  __________________________________
                  Do you Yahoo!?
                  Protect your identity with Yahoo! Mail AddressGuard
                  http://antispam.yahoo.com/whatsnewfree
                • SABRscouts@aol.com
                  Tom - I don t seem to find Doug Pappas list of assumptions for the Salary Data at his site , but I do believe his
                  Message 8 of 13 , Dec 7, 2003
                    Tom - I don't seem to find Doug Pappas' list of assumptions for the Salary Data at his site <http://roadsidephotos.com/baseball/>, but I do believe his information does reflect the actual salary paid for a given year.  In the Ramirez case, it shows 2002 at $15,462,727.00 and 2003 at $17,185,177.00.  For a thorough explanation, contact Doug at SABRBaseballBiz@....

                    Rod Nelson

                    In a message dated 12/7/2003 2:21AM MST, tmasc@... writes:

                    Date: Sat, 6 Dec 2003 13:49:49 -0800 (PST)
                      From: "tmasc@..." <tmasc@...>
                    Subject: SALARY

                    On the question of salary, this too should be
                    rethought.  Manny Ramirez may have signed a 8-yr 160
                    million$ contract, but that doesn't mean he's making
                    20 million$ / year. 

                    (For those who don't follow Present Value, if you win
                    the lottery, and we offered 10 million$ now, or 1
                    million$ per year for 11 years, what would you do?)

                    In terms of data recording, the contract should be
                    recorded as whatever it is.  So, what you first need
                    is a CONTRACT table, that shows what the payouts are
                    supposed to be, including bonuses etc.

                    How someone wants to interpret this in terms of luxury
                    tax purposes, or what happens with Mondesi being
                    traded mid-contract, and salaries being covered, etc,
                    is another issue.

                    The SALARY table is a little misleading because it
                    interprets the data in a way that others would
                    dispute.

                    In any case, there's probably not much for us to do
                    about it at this point. 

                    Tom


                  • tmasc@yahoo.com
                    ... My point is that the salary data should be recorded as-is (though converting a 10-page contract document into a 20 field record is a little daunting). The
                    Message 9 of 13 , Dec 7, 2003
                      --- SABRscouts@... wrote:
                      > Tom - I don't seem to find Doug Pappas' list of
                      > assumptions for the Salary
                      > Data at his site
                      > <http://roadsidephotos.com/baseball/>, but I do
                      > believe his
                      > information does reflect the actual salary paid for
                      > a given year. In the Ramirez
                      > case, it shows 2002 at $15,462,727.00 and 2003 at
                      > $17,185,177.00. For a
                      > thorough explanation, contact Doug at
                      > SABRBaseballBiz@....
                      >

                      My point is that the salary data should be recorded
                      as-is (though converting a 10-page contract document
                      into a 20 field record is a little daunting). The
                      interpretations/assumptions that follow that should
                      not be part of the database. The database should be
                      in the business of recording data.

                      However, given that we are a rag-tag collection of
                      volunteers, we take what we can get. The salary data
                      would be one place where an improvement should be
                      made.

                      My comment was more a theoretical comment than one for
                      practical consideration, right now.

                      Tom


                      __________________________________
                      Do you Yahoo!?
                      Protect your identity with Yahoo! Mail AddressGuard
                      http://antispam.yahoo.com/whatsnewfree
                    Your message has been successfully submitted and would be delivered to recipients shortly.