# 🗂️ Guide des fichiers SQL (où est la “vraie” base ?)

Ce dépôt contient plusieurs `.sql` avec des rôles différents (schéma, seed, dumps complets, migrations).

## ✅ Fichiers “schéma + seed” (pour initialiser une DB vide)

- `database-schema.sql`
  - Schéma principal + quelques données de configuration (ex: `app_config`, `badge_definitions`).
  - Utilisé par `docker/docker-compose.ovh.yml` (monté dans `/docker-entrypoint-initdb.d/`).
- `docker/init-fresh-database.sql`
  - **Copie exacte** de `database-schema.sql` (même hash).
- `docker/production/database/init.sql`
  - Variante “production” (pas strictement identique à `database-schema.sql`).

⚠️ Attention : ces fichiers ne garantissent pas d’être à 100% alignés avec la DB réelle si des migrations/patchs ont été appliqués ensuite.

## ✅ Dumps complets (schéma + TOUTES les données)

- `docker/faildaily_local_import_utf8.sql`
  - Dump complet de `faildaily` (structure + données).
  - Date du dump indiquée en fin de fichier (ex: `-- Dump completed on ...`).
- `docker/faildaily_logs_local_import.sql`
  - Dump complet de `faildaily_logs` (structure + données).
- `docs/archive/*.sql`
  - Anciens dumps/exports (archivés, souvent moins récents).

➡️ Pour migrer une base “réelle” (prod), c’est ce type de fichier qu’il faut utiliser (ou mieux: générer un dump frais depuis la prod).

## 🧩 Migrations / patchs (à appliquer sur une base existante)

- `migrations/*.sql`
- `backend-api/migrations/*.sql`
- `docker/fix-*.sql`

Ces fichiers servent à **ajouter/ajuster** des tables/colonnes quand le schéma a évolué.

## Recommandation (migration OVH/Cloud)

1. Faire un **dump frais** de la base source (prod) via `mysqldump` (idéalement depuis le conteneur MySQL).
2. Importer ce dump sur la base cible.
3. Vérifier rapidement la structure (`information_schema`, scripts de check, ou tests backend).