julien
a9ef4cf629
Rewrites all 7 backend ADRs from a custom structure to the MADR 2.1.2 template required by the VS Code ADR Manager extension: bullet metadata (Status/Date), standardised section headings, "Chosen option: X, because Y" wording, and explicit Pros/Cons blocks per option.
48 lines
2.2 KiB
Markdown
48 lines
2.2 KiB
Markdown
# Migrate from MongoDB to MySQL with Sequelize
|
|
|
|
* Status: accepted
|
|
* Date: 2026-04-26
|
|
|
|
## Context and Problem Statement
|
|
|
|
The project initially used MongoDB, likely chosen for its flexible schema during early prototyping (evidence: `mongo:start`/`mongo:stop` Docker scripts in `package.json`, `$oid` ObjectId references in original data exports). As the data model stabilised and relational queries became more common (joins between users, jumps, canopies, drop zones), a relational database became a better fit. Should the database be migrated?
|
|
|
|
## Considered Options
|
|
|
|
* Migrate to MySQL with Sequelize
|
|
* Keep MongoDB
|
|
|
|
## Decision Outcome
|
|
|
|
Chosen option: "Migrate to MySQL with Sequelize", because the data model is now stable and relational, and MySQL with Sequelize provides migrations, seeders, and relationship declarations that MongoDB cannot enforce at the database level.
|
|
|
|
Sequelize provides: model definitions with typed fields, a migration system (`sequelize-cli db:migrate`) for schema versioning, seeders for initial reference data, and relationship declarations (`src/database/relationships/`). The original MongoDB data was exported and re-imported into MySQL via a one-shot migration script (since removed).
|
|
|
|
### Positive Consequences
|
|
|
|
* Relational integrity enforced at the database level. Joins are first-class.
|
|
* Sequelize migrations provide a reproducible setup path (`npm run setup:api`).
|
|
|
|
### Negative Consequences
|
|
|
|
* Less flexible schema than MongoDB — changes require migrations.
|
|
|
|
## Pros and Cons of the Options
|
|
|
|
### MySQL with Sequelize
|
|
|
|
* Good, because enforces relational integrity at the database level.
|
|
* Good, because migrations provide a versioned, reproducible schema.
|
|
* Bad, because schema changes require explicit migration files.
|
|
|
|
### Keep MongoDB
|
|
|
|
* Good, because flexible schema — no migrations needed for model changes.
|
|
* Bad, because relational queries (joins) are complex and not first-class.
|
|
* Bad, because referential integrity is not enforced at the database level.
|
|
|
|
## Links
|
|
|
|
* The one-shot MongoDB → MySQL import script was removed from the frontend codebase (see `importJumps()` removal in `logbook.component.ts`).
|
|
* The `mongo:start`/`mongo:stop` npm scripts in `package.json` are legacy artefacts from the MongoDB era and can be removed.
|