Made a stab at an initial data model. No data is written yet, so plenty of opportunity to make any amount of changes necessary. So far, there are 10 models.
Models
There is an implicit model that I'm not really listing in the schema that represents the user. This will mostly be the players' parents/guardians but coaches will need to setup an account also, regardless of whether they have a youth on a team.
Registrant
This is the main model. This holds all the basic information about a person (player or coach) that is participating in a program. All other models will reference this one for things like name, birthdate, etc. Parents/guardians will have to create an account (see User above) with a password and basic contact information (phone number, email, street address) and a password. Their youth players will be “attached” to their user account. For now, youth will not be able to login on their own.
- id
- userId
- guardianId
- firstName
- lastName
- birthDate
- sex
- nickName
- photoUrl
Enrollee
This is someone who provided baseline information about a youth and has indicated that they are interested in participating in a Program (e.g. baseball, soccer). Keeping this separate should make differentiating pool players and incomplete teams from players/teams that are good to go.
- id
- registrantId
- programId
- enrollmentDate
- preference: This is a way for parents to provide some information on a team or teammate they'd like to play with.
Player
This represents a registrant that has found or been placed on a team. Again, this should aid in dealing with the pool. For example, if a Registrant doesn't have an active record in the Player table, then it must be a pool player. Or, if a team doesn't have some minimum number of Player records for a given season, then it is incomplete.
- id
- registrantId
- teamId
- jerseyNumber
Coach
Similar to Player, except this could be many-to-many, since many coaches have multiple teams.
- registrantId
- teamId
- position
Team
Pretty much what you'd expect. Each team is tied to a particular [Division](#division).
- id
- name
- logoUrl
- managerId: Links back to
Registrant
- divisionId
Program
Basically "baseball" "soccer" etc... These probably won't change much.
Division
This would be like: "Boys Soccer - 12U A" or something...
- id
- name
- description
- programId
- ageMin
- ageMax
Event
A generic event with datetime and location. Could be meetings, games, practice, etc.
- id
- name
- type
- description
- startDate
- endDate
- locationId
Game
A specific type of event. All games are events but not all events are games.
- id
- eventId
- homeTeamId
- awayTeamId
- homeTeamScore
- awayTeamScore
Location
Field information, but could also be used to represent stuff like "Rudy Room"
- id
- name
- playable
- latitude
- longitude
Made a stab at an initial data model. No data is written yet, so plenty of opportunity to make any amount of changes necessary. So far, there are 10 models.
Models
There is an implicit model that I'm not really listing in the schema that represents the user. This will mostly be the players' parents/guardians but coaches will need to setup an account also, regardless of whether they have a youth on a team.
Registrant
This is the main model. This holds all the basic information about a person (player or coach) that is participating in a program. All other models will reference this one for things like name, birthdate, etc. Parents/guardians will have to create an account (see User above) with a password and basic contact information (phone number, email, street address) and a password. Their youth players will be “attached” to their user account. For now, youth will not be able to login on their own.
Enrollee
This is someone who provided baseline information about a youth and has indicated that they are interested in participating in a Program (e.g. baseball, soccer). Keeping this separate should make differentiating pool players and incomplete teams from players/teams that are good to go.
Player
This represents a registrant that has found or been placed on a team. Again, this should aid in dealing with the pool. For example, if a Registrant doesn't have an active record in the
Playertable, then it must be a pool player. Or, if a team doesn't have some minimum number ofPlayerrecords for a given season, then it is incomplete.Coach
Similar to
Player, except this could be many-to-many, since many coaches have multiple teams.Team
Pretty much what you'd expect. Each team is tied to a particular
[Division](#division).RegistrantProgram
Basically "baseball" "soccer" etc... These probably won't change much.
Division
This would be like: "Boys Soccer - 12U A" or something...
Event
A generic event with datetime and location. Could be meetings, games, practice, etc.
Game
A specific type of event. All games are events but not all events are games.
Location
Field information, but could also be used to represent stuff like "Rudy Room"