# 4. Base de données et migrations

## Modèle général

Le schéma Prisma contient environ 68 modèles. Les familles principales sont :

| Famille | Tables représentatives |
|---|---|
| Salarié | `employes`, `contrats`, `avenants_contrat`, `absences`, `diplomes`, `visites_medicales`, `disciplinaire` |
| Référentiels | `etablissement`, `secteurs`, `postes`, `types_contrat_salarie`, `types_absence`, `types_diplome` |
| Alertes | `alertes`, `listes_alertes`, `mails_alertes`, `alertes_mail_envois` |
| Sécurité | `auth_users`, `auth_user_permissions` et tables de scopes |
| Documents | `modeles_documents`, `versions_modeles_documents`, `documents`, `impressions` |
| Procédures | `procedure_requests`, `procedure_followups`, `procedure_request_history`, `employee_communications` |
| Paramétrage | `parametres`, `signataires`, destinataires secteur/RH, compteurs système |

## Relations métier majeures

- `contrats.Id_Salarie` référence le `COS` du salarié, pas sa clé interne.
- `avenants_contrat.id_contrat` référence `contrats.ID_Contrat`.
- `diplomes.id_salarie` utilise la clé interne `employes.id`.
- alertes et visites utilisent majoritairement le `COS`.
- les tables d’habilitation référencent `auth_users.id` et les référentiels associés.

Avant toute requête corrective, vérifier la colonne exacte utilisée par la relation. Les noms hérités d’Access ne sont pas homogènes.

## Prisma : procédure normale

Pour une base neuve :

```bash
docker compose exec backend npx prisma migrate deploy --schema prisma/schema.prisma
docker compose exec backend npx prisma migrate status --schema prisma/schema.prisma
```

Pour une modification de schéma en développement :

1. modifier `schema.prisma` ;
2. créer une migration nommée et relire son SQL ;
3. appliquer sur une copie de données ;
4. régénérer le client Prisma ;
5. tester le backend ;
6. versionner schéma et migration ensemble.

## Cas historique : erreur P3005

`P3005: The database schema is not empty` signifie que Prisma découvre une base déjà remplie sans historique de migrations compatible. Il ne faut ni vider la base ni répéter `migrate deploy`.

La bonne démarche est un baseline contrôlé :

1. sauvegarder la base ;
2. comparer le schéma réel au schéma attendu ;
3. déterminer quelles migrations sont déjà représentées dans la structure ;
4. marquer seulement ces migrations comme appliquées avec `prisma migrate resolve --applied <migration>` ;
5. appliquer les migrations restantes sur une copie ;
6. valider avant production.

Le baseline est une décision technique à tracer. Marquer toutes les migrations comme appliquées sans comparaison peut masquer une colonne manquante, comme `auth_users.signature_enabled`.

## Migration Access vers MySQL

La méthode retenue est isolée :

| Base | Rôle |
|---|---|
| `app_db` | Base RH Connect actuellement utilisée ; ne pas modifier pendant la préparation |
| `access_raw_20260828` | Import brut depuis la copie Access |
| `app_db_candidate_20260828` | Copie de RH Connect enrichie avec les données Access |

Séquence : sauvegarde `app_db`, copie immuable du `.accdb`, import Access brut, inventaires, copie de `app_db` vers la candidate, fusion SQL dans la candidate, recalcul du statut actif, validations, tests applicatifs, export de la candidate, puis bascule de production.

Lors d’un nouvel import Access, utiliser une copie locale du fichier source. La présence de `BaseSalariés_Données.laccdb` indique qu’un utilisateur peut avoir la base ouverte ; ne jamais travailler directement sur le partage réseau.

## Contrôles minimaux avant bascule

- nombre total de salariés et actifs expliqué ;
- aucun `COS` nul ou dupliqué ;
- aucun `ID_Contrat` métier dupliqué ;
- aucun contrat sans salarié ;
- aucune date de fin antérieure au début ;
- aucun avenant sans contrat ;
- aucun statut actif différent du calcul attendu ;
- anomalies historiques documentées ;
- connexion et parcours métier testés contre la candidate.

## Sauvegarde MySQL

```bash
docker compose exec -T db sh -lc \
  'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" --single-transaction --routines --triggers app_db' \
  > app_db-$(date +%Y%m%d-%H%M%S).sql
sha256sum app_db-*.sql
```

Une sauvegarde utile doit avoir une taille plausible, un hash conservé et un test de restauration dans une base temporaire.