-
-
Notifications
You must be signed in to change notification settings - Fork 1
HOWTO prj DB_overview
-
All project apps & sub-apps share the same core DB structure & models, defined inside the namespaced engine
goggles_db("GogglesDb"). -
GogglesDbdefines all base objects & Models for the framework, as well as the initial structure, evolved from the previous versions. -
All original migrations stored inside
goggles_dbare considered "cold", meaning as being "part of the groundwork for achieving the initial structure" and shouldn't be updated or touched unless a major release upgrade is planned. -
All subsequent migrations (past the original ones) should be stored just inside
goggles_mainand considered as "warm", meaning as "supposed to be checked for status upon each service run and executed if not online". -
Typically, DB versioning is kept independent from the actual framework or container version.
(I will assume you have at least a vague idea of how a Swimming competition works: it should be enough.)
The DB aims to store all information regarding a "Swimming Meeting", with all its events divided by type and age groups (categories) - plus much more, but we'll limit ourselves to this for the time being.
A Meeting can store any race result both from individual or from team/group events (that is, "relays").
Each result can consist of 1 or more laps. Each lap can have a timing for completion, a reaction time and many other properties, depending on the type of event the lap or the "final" result refers to.
Attending athletes usually go through a "registration phase", handled by a Team Manager. The total event registrations for each athlete usually is limited to 4-5 events tops - but that may change from Meeting to Meeting and depends also on the type of Championship the Meeting is into.
Each athlete (Swimmer) must belong to a Team, which, in turn, must be registered for a specific Championship Season of a given Federation.
Thus, we have roughly:
- many Federations;
- each Federation may issue many Championship;
- each Championship can have many Seasons;
- each Season can host many Meetings;
- each Meeting can have many Events;
- each Event can be "individual" or "relay";
- each Event has many "Programs", dividing the event into age & sex groups;
- each "Program" can have many results;
- each "Result" can refer to many laps (or none) as well as many swimmers (relays) or just one (individual result);
- each Meeting gives also an overall score for the enrolled Team, depending on Championship rules and Meeting-specific exceptions.
Each athlete enrolled in a competition usually has a badge number associated to him - except in Regional or Local competitions where this is more the exception than the norm.
In any case, it's responsibility of the Team (managers) to handle the registration phase and renew all athletes' badges for each Championship in which the Team has or wants to enroll.
This adds also the Team's affiliation with any Championship as well as its swimmers:
- each Team can have many Affiliations with any Championship's Season;
- each Team Affiliation can relate to many Swimmers' badges (badges change from Season to Season);
- each Swimmer can have many Badges (one for each Championship's Season in which takes part);
- each Swimmer Badge can be registered for many events in a Meeting.
When a Swimmer registers for an event in a Meeting, usually an expected qualify timing is given. This yield a Meeting Entry, which is a totally different beast from the actual Meeting Result that the Athlete gets when the race is done.
The total set of registration entries for a Meeting gives the actual "start-list" used to prepare & divide the events in the competition: the "start-list" is divided by event categories (age groups and sex), ordered by descending time and only after that the competition can really start divided in events.
What follows is a high-level overview of the main associations between the most important entity clusters in the current implementation.
TO-DO: graph
TO-DO: graph
TO-DO: graph