Skip to content
This repository was archived by the owner on Apr 29, 2025. It is now read-only.

4. MongoDB Database πŸ—„οΈ

Laura Leschke edited this page Aug 14, 2024 · 14 revisions

4.1 Schema Design πŸ—οΈ

GREAT STAFF uses MongoDB for its flexible schema design. The database is structured into two main instances:

  1. Development Database: great-staff-database
  2. Production Database: great-staff-database-prod

Both databases contain the following collections:

  • assignments
  • contracts
  • demands
  • leaves
  • projectdemandprofiles
  • projects
  • projectworkinghours
  • skillcategories
  • skills
  • users

4.2 Data Models+Structure 🚦

Assignment

{
  _id: ObjectId,
  userId: [ObjectId], // Array of User IDs
  projectDemandProfileId: ObjectId, // Profile ID
  createdAt: Date,
  updatedAt: Date,
  __v: Number
}

Required fields: projectDemandProfileId

Contract (for future development)

{
  _id: ObjectId,
  startDate: Date,
  endDate: Date,
  weeklyWorkingHours: Number, // between 0 and 40
  createdAt: Date,
  updatedAt: Date,
  __v: Number
}

Required fields: startDate, weeklyWorkingHours

Leave (for future development)

{
  _id: ObjectId,
  startDate: Date,
  endDate: Date,
  createdAt: Date,
  updatedAt: Date,
  __v: Number
}

Required fields: startDate, endDate

Demand

{
  _id: ObjectId,
  now: Number,
  nextQuarter: Number, // for future development
  nextNextQuarter: Number, // for future development
  createdAt: Date,
  updatedAt: Date,
  __v: Number
}

Required fields: now

ProjectDemandProfile

{
  _id: ObjectId,
  name: String,
  targetDemandId: ObjectId, // reference to a Demand document
  targetSkills: [ObjectId], // Array of Skill IDs
  createdAt: Date,
  updatedAt: Date,
  __v: Number
}

Required fields: name, targetDemandId

Project

{
  _id: ObjectId,
  projectName: String, // max 50 characters
  kickoffDate: Date,
  deadlineDate: Date,
  projectLocation: String, // max 100 characters
  demandProfiles: [ObjectId], // Array of ProjectDemandProfile IDs
  priority: String, // defined in an Enum
  createdAt: Date,
  updatedAt: Date,
  __v: Number
}

Required fields: projectName, kickoffDate

ProjectWorkingHour

{
  _id: ObjectId,
  date: Date,
  numberOfRealWorkingHours: Number,
  userId: String, // reference
  projectId: String // reference
  createdAt: Date,
  updatedAt: Date,
  __v: Number
}

Required fields: date, numberOfRealWorkingHours, userId, projectId

SkillCategory

{
  _id: ObjectId, // unique
  name: String,
  maxPoints: Number,
  createdAt: Date,
  updatedAt: Date,
  __v: Number
}

Required fields: name, maxPoints

Skill

{
  _id: ObjectId,
  skillPoints: Number,
  skillCategory: ObjectId, // reference
  createdAt: Date,
  updatedAt: Date,
  __v: Number
}

Required fields: skillPoints, skillCategory

User

{
  _id: ObjectId,
  firstName: String, // max 5 characters
  lastName: String, // max 5 characters
  email: String, // unique, max 5 characters
  password: String, // min 5 characters
  canWorkRemote: Boolean, // by default false
  leaveIds: [ObjectId], // Array of Leave IDs
  skills: [ObjectId], // Array of Skill IDs
  officeLocation: String, // defined in an Enum
  roles: [String], // defined in an Enum
  contractId: ObjectId, // reference
  targetSkills: [ObjectId] // Array of Skill IDs
  createdAt: Date,
  updatedAt: Date,
  __v: Number,

}

Required fields: firstName, lastName, email, password

4.3 Relationships πŸ”‚

GREAT STAFF uses a mix of embedded documents and references to represent relationships:

  1. Users to Skills:

    • Array of Skill ObjectIds in User document (skills and targetSkills fields)
  2. Projects to ProjectDemandProfiles:

    • Array of ProjectDemandProfile ObjectIds in Project document (demandProfiles field)
  3. Assignments:

    • References both User (userId field) and ProjectDemandProfile (projectDemandProfileId field)
  4. Users to Contracts:

    • Reference to Contract in User document (contractId field)
  5. ProjectDemandProfiles to Skills:

    • Array of Skill ObjectIds in ProjectDemandProfile document (targetSkills field)

4.4 Backup, Restore, and Daily Reset

GREAT STAFF implements automated daily backups and resets using GitHub Actions.

Key features:

  • Daily backup of the production database at 2:00 AM German time (MESZ) // (UTC+2)
  • Daily reset of the development database to the state of the production database at 2:00 AM German time (MESZ) // (UTC+2)

The workflow for this process is defined in .github/workflows/daily-db-backup.yml. For more details on the CI/CD process, including this database reset, refer to 5. Deployment, CI/CD & GitHub Actions.

To manually backup or restore:

  1. Backup:

    mongodump --uri="<MONGO_URL>" --out=<backup_directory>
    
  2. Restore:

    mongorestore --uri="<MONGO_URL>" <backup_directory>
    

Replace <MONGO_URL> with the appropriate connection string.

To manually trigger the workflow in GitHub Actions klick "Run workflow" like indicated in the image. image

Link to the Workflow

4.5 MongoDB Configuration Secrets

GREAT STAFF uses GitHub Secrets to manage MongoDB configuration securely. These secrets are used in GitHub Actions workflows and deployment processes.

Key MongoDB-related secrets:

  • MONGO_DATABASE: Development database name (great-staff-database)
  • MONGO_DATABASE_PROD: Production database name (great-staff-database-prod)
  • MONGO_HOST: Development MongoDB host
  • MONGO_HOST_PROD: Production MongoDB host
  • MONGO_PASSWORD: MongoDB user password
  • MONGO_URL: Full connection string for development
  • MONGO_URL_PROD: Full connection string for production
  • MONGO_USER: MongoDB username

To update these secrets:

  1. Go to the GitHub repository settings
  2. Navigate to Secrets and Variables > Actions
  3. Update the relevant secret values