- Calendars one-to-one with: people, courts, meeting rooms.
- Courts and meeting rooms are both building resources.
- Courts have a surface type, meeting rooms do not.
- Buildings one-< many with resources, including courts
- Calendar -< events
- People >-< events
- Location >- events
- Events -< Sessions, but Sessions are not entities. Events one-to-one with RecurranceRules. See Designing Calendar Events
- People can be: customers, students, coaches, employees (these are interfaces, define properties to be implemented as backing fields).
- People table — contains all shared identity data
- OrgRoleDetails tables (StudentDetails, CoachDetails, etc) — foreign key relationships with People, allow for multiple orgroles per person.
- AppUser one-to-one with Person. All users are people, not all people are app users with login credentials. The AppUser table is used for business logic related only to authentication and app roles. All business logic related to org roles, scheduling, calendars, etc. shall depend solely on the Person table. Person and User may very well be used by other applications. Use GUIDs as primary keys.
- User -< with Roles. Roles are currently undefined.
- Exceptions >-< with Events.
- Events: show who created the event, even if it’s not on their calendar, show datetime created, edited, deleted, archived.
- Exceptions: have all the metadata an Event has, not just a Session. Show datetime created
