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

RE: [baseball-databank] Digest Number 392

Expand Messages
  • tmasc@yahoo.com
    ... The MASTER table, once we get done with the redesign, will include umpires, Japanese players, Negro leaguers, managers, minor leaguers, etc. The MASTER
    Message 1 of 13 , Dec 4, 2003
    • 0 Attachment
      --- 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
    • 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 2 of 13 , Dec 4, 2003
      • 0 Attachment
        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 3 of 13 , Dec 4, 2003
        • 0 Attachment
          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 4 of 13 , Dec 4, 2003
          • 0 Attachment
            -----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 5 of 13 , Dec 5, 2003
            • 0 Attachment
              --- 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 6 of 13 , Dec 5, 2003
              • 0 Attachment
                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 7 of 13 , Dec 5, 2003
                • 0 Attachment
                  --- 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 8 of 13 , Dec 6, 2003
                  • 0 Attachment
                    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 9 of 13 , Dec 7, 2003
                    • 0 Attachment
                      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 10 of 13 , Dec 7, 2003
                      • 0 Attachment
                        --- 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.