# Migrations SQL

Ce répertoire contient les migrations SQL versionnées pour la base de données Formation Manager Itinova.

## Format des fichiers

Les fichiers de migration doivent suivre ce format de nommage :
```
YYYYMMDD-description.sql
```

Exemples :
- `20260113-fix-schema.sql`
- `20260120-add-notifications.sql`
- `20260201-update-rappels.sql`

## Ordre d'application

Les migrations sont appliquées dans l'ordre alphabétique (donc chronologique grâce au format de date).

## Syntaxe

Utilisez la syntaxe MySQL compatible avec les versions 5.7+.

Pour les opérations ALTER TABLE, utilisez `IF NOT EXISTS` ou `IF EXISTS` quand c'est supporté, ou gérez les erreurs dans le script de mise à jour.

## Exemple de migration

```sql
-- Migration YYYYMMDD: Description courte
-- Description détaillée de ce que fait cette migration

-- Ajouter une nouvelle table
CREATE TABLE IF NOT EXISTS nouvelle_table (
    id INT AUTO_INCREMENT PRIMARY KEY,
    nom VARCHAR(255) NOT NULL,
    createdAt TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- Modifier une table existante
ALTER TABLE users 
ADD COLUMN IF NOT EXISTS nouveau_champ VARCHAR(100);

-- Ajouter un index
ALTER TABLE users
ADD INDEX IF NOT EXISTS idx_users_nouveau_champ (nouveau_champ);

-- Insérer des données par défaut
INSERT IGNORE INTO nouvelle_table (nom) VALUES ('Valeur par défaut');
```

## Suivi des migrations

Le script de mise à jour crée automatiquement une table `schema_migrations` qui enregistre :
- La version (nom du fichier sans .sql)
- La date d'application
- Une description

## Créer une nouvelle migration

1. Créez un fichier avec le format de nommage correct
2. Écrivez votre migration SQL
3. Testez-la sur une base de données de développement
4. Incluez-la dans le package de déploiement

## Rollback

Pour annuler une migration, créez une nouvelle migration qui fait l'opération inverse.

Exemple : Si `20260113-add-column.sql` ajoute une colonne, créez `20260114-remove-column.sql` qui la supprime.

## Bonnes pratiques

1. **Toujours tester** sur une base de développement avant de déployer
2. **Sauvegarder** la base de données avant d'appliquer des migrations (fait automatiquement par le script)
3. **Être idempotent** : la migration doit pouvoir être exécutée plusieurs fois sans erreur
4. **Documenter** : ajouter des commentaires expliquant le but de chaque modification
5. **Atomique** : chaque migration doit être une unité logique de changement
6. **Rétrocompatible** : éviter de supprimer des colonnes utilisées par l'ancienne version