Re: baseball league db design

John O'Conner <jsoconner_at_earthlink.nospam.net> wrote:
>I've volunteered to create a db for a Little League Baseball league. My

>question is about designing the db tables...
>
>Although I haven't finished my complete model, I've started to model the

>following:
>ROLE
> RoleID
> Name
>ADDRESS
> AddressID
> Address1
> Address2
> City
> State
> PostalCode
>PARTICIPANT
> ParticpantID
> ???
>
>I had planned to put everyone (coaches, mgrs, players, etc) in the
>PARTICIPANT table, distinguished by their various ROLES. Since every
>PARTICIPANT can have 1 or more ROLES, I had planned to store ROLES in a

>separate PARTICIPANT_ROLES table.
>
>Now my question...what should PARTICIPANT contain? Obvious candidates
>are first/last names, an address id, phone, fax, and email addresses for

>contact information. However, the young players will eventually have
>much more information like position, birthdate, team assignment, number,

>maybe some other stats. It doesn't seem right to put those in the
>PARTICIPANT table since not all participants will use those fields. Now

>I'm thinking that maybe I need to treat players differently from other
>particpants...in a separate table perhaps.
>
>Can anyone provide any advice on how I should design a db for a little
>league? Obviously I'm a little over my head with the design/schema.
>
>Your help will be much appreciated. I'm no professional db mgr/admin
>obviously...just doing this to help out.
>
>Best regards,
>John O'Conner
>
Most little league databases don't care about team, position, and number.  From a management perspective, these attributes are irrelevant to running the league. You do have different types of Participants however. And these participants have different attributes based on their Role. In these cases, a super/sub type data structure is applicable. Received on Fri Jan 23 2004 - 14:57:35 CET