# Fichier: python_cheats/cheatsheets/base_de_donnees.txt
# GUIDE COMPLET DES BASES DE DONNÉES - Pour Grands Débutants
# MySQL | SQLite | PostgreSQL | MongoDB
# Comprendre TOUT : Structure, Architecture, Exécution, Différences

[OK] INTRODUCTION : POURQUOI CE GUIDE ?

# Tu débutes COMPLÈTEMENT avec les bases de données ?
# Ce guide est fait pour TOI !

# Objectif :
# Te faire comprendre EXACTEMENT ce qu'est une base de données
# Découvrir les différents types : SQL (relationnel) vs NoSQL (document)
# Maîtriser MySQL, SQLite, PostgreSQL, MongoDB
# Comprendre comment fonctionne CHAQUE système sous le capot
# Savoir QUAND utiliser quelle base de données
# Voir le voyage COMPLET d'une requête, du clavier au disque dur

# Plan du guide :
# 1. Qu'est-ce qu'une base de données ? (concepts fondamentaux)
# 2. Types de bases de données : SQL vs NoSQL
# 3. MySQL : architecture et fonctionnement
# 4. SQLite : la base de données embarquée
# 5. PostgreSQL : le SGBD open-source le plus avancé
# 6. MongoDB : la base de données NoSQL documentaire
# 7. Comparaisons détaillées et différences
# 8. Voyage complet d'une requête dans chaque SGBD
# 9. Stockage physique et moteurs
# 10. Optimisation et performance
# 11. Comment choisir la bonne base de données ?


[OK] PARTIE 1 : QU'EST-CE QU'UNE BASE DE DONNÉES ?

# === DÉFINITION ULTRA-SIMPLE ===

"""
Une BASE DE DONNÉES, c'est comme un CLASSEUR GÉANT INTELLIGENT qui :

[OK] STOCKE des informations de manière ORGANISÉE
[OK] RETROUVE ces informations TRÈS RAPIDEMENT
[OK] GARANTIT que les informations restent COHÉRENTES
[OK] PERMET à plusieurs personnes de travailler EN MÊME TEMPS
[OK] PROTÈGE les informations contre les pannes et les erreurs
[OK] EMPÊCHE les accès non autorisés

EXEMPLE CONCRET : Site e-commerce
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Un site comme Amazon a besoin de stocker :
-> Des millions de CLIENTS (nom, email, adresse, mot de passe)
-> Des millions de PRODUITS (nom, prix, description, stock)
-> Des millions de COMMANDES (qui a acheté quoi, quand, combien)
-> Des AVIS clients, des PAIEMENTS, des LIVRAISONS, etc.

IMPOSSIBLE à gérer avec de simples fichiers texte ! 
-> Il faut une BASE DE DONNÉES
"""

# === ANALOGIE : LA BIBLIOTHÈQUE VS L'ENTREPÔT ===

"""
┌────────────────────────────────────────────────────────────────────┐
│                    SANS BASE DE DONNÉES                            │
│                    (Entrepôt en désordre)                          │
└────────────────────────────────────────────────────────────────────┘

Imagine un ENTREPÔT où :
[PACKAGE] Des millions de boîtes sont empilées au hasard
[X] Aucune organisation, aucun catalogue
[X] Pour trouver quelque chose, tu dois ouvrir TOUTES les boîtes
[X] Plusieurs personnes veulent la même boîte -> CONFLIT
[X] Quelqu'un déplace une boîte -> tu ne la retrouves JAMAIS
[X] Quelqu'un prend un produit -> le stock n'est pas mis à jour
[ALARM_CLOCK] Recherche : Des HEURES voire des JOURS

PROBLÈMES CONCRETS avec de simples fichiers :

clients.txt :
Jean Dupont,30,Paris,jean@email.com
Marie Martin,25,Lyon,marie@email.com
Pierre Durand,35,Paris,pierre@email.com
...
(des millions de lignes)

1. Comment chercher tous les clients de Paris ?
   -> Tu dois lire TOUT le fichier ligne par ligne (O(n))
   -> Sur 10 millions de lignes : plusieurs MINUTES [LENT]

2. Comment garantir qu'on n'insère pas deux fois le même email ?
   -> Impossible sans vérifier manuellement toutes les lignes
   -> Risque de DOUBLONS

3. Que se passe-t-il si deux programmes modifient le fichier en même temps ?
   -> CORRUPTION des données !
   -> Perte d'informations

4. Comment gérer les relations entre tables ?
   -> clients.txt, commandes.txt, produits.txt
   -> Très compliqué de faire des jointures manuellement

5. Comment récupérer après un crash ?
   -> Fichier corrompu -> tout est perdu !


┌────────────────────────────────────────────────────────────────────┐
│                    AVEC BASE DE DONNÉES                            │
│                    (Bibliothèque organisée)                        │
└────────────────────────────────────────────────────────────────────┘

Maintenant imagine une BIBLIOTHÈQUE moderne où :
[DOCS] Chaque livre a un code unique (identifiant)
[DOSSIER] Un catalogue informatisé (index) pour tout retrouver instantanément
[RECHERCHE] Tu tapes "clients de Paris" -> RÉSULTAT EN 0.01 SECONDE
[OK] Plusieurs personnes peuvent consulter en même temps sans conflit
[OK] Le système GARANTIT qu'il n'y a jamais de doublons
[OK] Toutes les modifications sont JOURNALISÉES (log)
[OK] En cas de panne, le système RÉCUPÈRE automatiquement
[OK] Les relations entre données sont AUTOMATIQUES (clés étrangères)
[ALARM_CLOCK] Recherche : MILLISECONDES [RAPIDE]

AVEC UNE BASE DE DONNÉES :

-- Recherche ultra-rapide
SELECT * FROM clients WHERE ville = 'Paris';
-> Résultat INSTANTANÉ grâce aux INDEX (B-Tree, Hash...)
-> Même sur 10 millions de lignes : quelques MILLISECONDES

-- Garanties d'unicité
CREATE TABLE clients (
    id INT PRIMARY KEY,        -- Impossible d'avoir deux ID identiques
    email VARCHAR(200) UNIQUE  -- Impossible d'avoir deux emails identiques
);

-- Transactions ACID (Atomicité, Cohérence, Isolation, Durabilité)
BEGIN TRANSACTION;
    UPDATE comptes SET solde = solde - 100 WHERE id = 1;  -- Débit
    UPDATE comptes SET solde = solde + 100 WHERE id = 2;  -- Crédit
COMMIT;
-> Soit les DEUX opérations réussissent, soit AUCUNE
-> Jamais de situation incohérente (argent perdu ou créé)

-- Concurrence gérée automatiquement
-> 1000 utilisateurs en même temps -> aucun problème
-> Le SGBD gère les verrous (locks) automatiquement

-- Récupération après panne
-> Toutes les transactions sont dans un JOURNAL (WAL/Redo Log)
-> En cas de crash, le système REJOUE les opérations perdues
"""

# === COMPOSANTS D'UNE BASE DE DONNÉES ===

"""
┌────────────────────────────────────────────────────────────────────┐
│              COMPOSANTS D'UN SYSTÈME DE BASE DE DONNÉES            │
└────────────────────────────────────────────────────────────────────┘

1. SGBD (Système de Gestion de Base de Données)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
C'est le LOGICIEL qui gère tout :
-> MySQL, PostgreSQL, SQLite, MongoDB, Oracle, SQL Server...

Responsabilités du SGBD :
[OK] Parser et optimiser les requêtes
[OK] Gérer le stockage physique des données
[OK] Maintenir les index pour la performance
[OK] Gérer la concurrence (plusieurs utilisateurs)
[OK] Garantir l'intégrité des données (contraintes)
[OK] Gérer la sécurité (authentification, permissions)
[OK] Assurer la durabilité (journalisation, sauvegardes)


2. BASE DE DONNÉES (Database)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
C'est le CONTENEUR logique pour tes données :
-> Une base = un projet
-> Ex: "ecommerce", "blog", "gestion_stocks"

Un SGBD peut gérer PLUSIEURS bases :
MySQL Server
  ├── ecommerce (base 1)
  ├── blog (base 2)
  └── analytics (base 3)


3. TABLES (ou COLLECTIONS pour NoSQL)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
C'est où sont STOCKÉES les données :
-> Table = feuille Excel avec des colonnes et des lignes
-> Chaque ligne = un enregistrement (row/tuple/document)

Exemple :
Table "clients"
┌────┬──────────────┬─────┬────────────────────────┬────────┐
│ id │     nom      │ age │         email          │ ville  │
├────┼──────────────┼─────┼────────────────────────┼────────┤
│  1 │ Jean Dupont  │  30 │ jean@example.com       │ Paris  │
│  2 │ Marie Martin │  25 │ marie@example.com      │ Lyon   │
│  3 │ Luc Bernard  │  35 │ luc@example.com        │ Paris  │
└────┴──────────────┴─────┴────────────────────────┴────────┘


4. SCHÉMA (Schema)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
C'est la STRUCTURE de tes données :
-> Quelles tables existent ?
-> Quelles colonnes dans chaque table ?
-> Quels types de données ? (INT, VARCHAR, DATE...)
-> Quelles contraintes ? (NOT NULL, UNIQUE, FOREIGN KEY...)

CREATE TABLE clients (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nom VARCHAR(100) NOT NULL,
    age INT CHECK (age >= 0 AND age <= 150),
    email VARCHAR(200) UNIQUE NOT NULL,
    ville VARCHAR(50),
    date_creation TIMESTAMP DEFAULT NOW()
);

Schéma = le PLAN architectural de ta base


5. INDEX
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
C'est la "table des matières" pour accélérer les recherches :
-> Comme l'index d'un livre
-> Permet de retrouver instantanément une ligne

CREATE INDEX idx_ville ON clients(ville);

Sans index : recherche O(n) - linéaire - LENT [LENT]
Avec index : recherche O(log n) - logarithmique - RAPIDE [RAPIDE]

Sur 1 million de lignes :
Sans index : 1 000 000 comparaisons
Avec index : ~20 comparaisons seulement !


6. TRANSACTIONS
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
C'est un ENSEMBLE d'opérations qui doivent réussir TOUTES ou AUCUNE :

BEGIN TRANSACTION;
    -- Retirer 100€ du compte A
    UPDATE comptes SET solde = solde - 100 WHERE id = 1;
    
    -- Ajouter 100€ au compte B
    UPDATE comptes SET solde = solde + 100 WHERE id = 2;
COMMIT;

SI une opération échoue -> ROLLBACK (annulation totale)
-> Jamais de situation bancale (argent perdu dans la nature)

Propriétés ACID :
A = Atomicité : tout ou rien
C = Cohérence : état valide avant et après
I = Isolation : les transactions ne se perturbent pas
D = Durabilité : validé = permanent (même après crash)


7. LANGAGE DE REQUÊTE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
C'est comment tu COMMUNIQUES avec la base :

SQL (Structured Query Language) pour bases relationnelles :
-> MySQL, PostgreSQL, SQLite, Oracle, SQL Server

-- Lire des données
SELECT nom, age FROM clients WHERE ville = 'Paris';

-- Insérer des données
INSERT INTO clients (nom, age, email, ville) 
VALUES ('Paul Durand', 28, 'paul@example.com', 'Lyon');

-- Modifier des données
UPDATE clients SET age = 31 WHERE id = 1;

-- Supprimer des données
DELETE FROM clients WHERE id = 3;

NoSQL (Not Only SQL) pour bases non-relationnelles :
-> MongoDB : JavaScript-like (JSON)

// Lire
db.clients.find({ ville: "Paris" })

// Insérer
db.clients.insertOne({
    nom: "Paul Durand",
    age: 28,
    email: "paul@example.com",
    ville: "Lyon"
})
"""


[OK] PARTIE 2 : TYPES DE BASES DE DONNÉES - SQL VS NOSQL

# === BASES DE DONNÉES RELATIONNELLES (SQL) ===

"""
┌────────────────────────────────────────────────────────────────────┐
│             BASES DE DONNÉES RELATIONNELLES (SQL)                  │
└────────────────────────────────────────────────────────────────────┘

PRINCIPE FONDAMENTAL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Les données sont organisées en TABLES reliées entre elles
-> Comme dans Excel : lignes et colonnes
-> Relations entre tables via des CLÉS

STRUCTURE : TABLES (Relations)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Table CLIENTS :
┌────┬──────────────┬────────────────────────┐
│ id │     nom      │         email          │  <- PRIMARY KEY : id
├────┼──────────────┼────────────────────────┤
│  1 │ Jean Dupont  │ jean@example.com       │
│  2 │ Marie Martin │ marie@example.com      │
└────┴──────────────┴────────────────────────┘

Table COMMANDES :
┌────┬────────────┬──────────┬─────────────┐
│ id │ client_id  │ montant  │    date     │  <- FOREIGN KEY : client_id
├────┼────────────┼──────────┼─────────────┤
│  1 │     1      │  150.00  │ 2024-01-15  │  -> Référence client id=1
│  2 │     1      │  220.00  │ 2024-01-20  │  -> Référence client id=1
│  3 │     2      │  85.00   │ 2024-01-18  │  -> Référence client id=2
└────┴────────────┴──────────┴─────────────┘

RELATION :
clients.id (PRIMARY KEY) <--> commandes.client_id (FOREIGN KEY)

JOINTURE (JOIN) :
SELECT c.nom, co.montant, co.date
FROM clients c
JOIN commandes co ON c.id = co.client_id
WHERE c.nom = 'Jean Dupont';

Résultat :
┌──────────────┬──────────┬─────────────┐
│     nom      │ montant  │    date     │
├──────────────┼──────────┼─────────────┤
│ Jean Dupont  │  150.00  │ 2024-01-15  │
│ Jean Dupont  │  220.00  │ 2024-01-20  │
└──────────────┴──────────┴─────────────┘


AVANTAGES DES BASES RELATIONNELLES :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[OK] STRUCTURE CLAIRE ET RIGIDE
-> Schéma défini à l'avance (colonnes, types)
-> Impossible d'insérer n'importe quoi

[OK] INTÉGRITÉ RÉFÉRENTIELLE
-> Impossible de supprimer un client qui a des commandes (FOREIGN KEY)
-> Les données restent COHÉRENTES

[OK] NORMALISATION
-> Évite la duplication des données
-> Chaque information n'est stockée qu'UNE FOIS

[OK] TRANSACTIONS ACID
-> Garanties fortes de cohérence
-> Parfait pour les applications critiques (banque, e-commerce)

[OK] LANGAGE STANDARD (SQL)
-> Même langage pour MySQL, PostgreSQL, Oracle, SQL Server
-> Compétences transférables

[OK] REQUÊTES COMPLEXES
-> Jointures multiples
-> Sous-requêtes
-> Agrégations (SUM, AVG, COUNT, GROUP BY)

[OK] MATURITÉ
-> 40+ ans d'existence
-> Très fiables, testés en production depuis des décennies


INCONVÉNIENTS :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[X] SCHÉMA RIGIDE
-> Difficile de modifier la structure après coup (ALTER TABLE)
-> Pas flexible pour des données variables

[X] SCALABILITÉ HORIZONTALE DIFFICILE
-> Difficile de répartir sur plusieurs serveurs (sharding complexe)
-> Les jointures entre serveurs sont problématiques

[X] PERFORMANCES SUR TRÈS GROS VOLUMES
-> Jointures coûteuses sur des milliards de lignes
-> Index B-Tree moins efficaces que des structures NoSQL spécialisées

[X] PAS ADAPTÉ AUX DONNÉES HIÉRARCHIQUES
-> JSON, XML, arbres -> difficile à modéliser en tables


QUAND UTILISER UNE BASE RELATIONNELLE (SQL) ?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[OK] Applications critiques (banque, comptabilité, ERP)
-> Besoin de garanties ACID fortes

[OK] Données structurées avec relations claires
-> Clients <-> Commandes <-> Produits

[OK] Requêtes complexes avec jointures
-> Rapports, analyses, agrégations

[OK] Intégrité référentielle importante
-> Impossible d'avoir des données orphelines

[OK] Volume modéré (jusqu'à quelques millions de lignes)
-> Bonnes performances avec optimisation

Exemples :
-> Site e-commerce (Amazon, eBay)
-> Système de gestion clients (CRM)
-> Application bancaire
-> ERP d'entreprise
-> Système de réservation


PRINCIPAUX SGBD RELATIONNELS :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. MySQL / MariaDB
   -> Le plus populaire
   -> Gratuit et open-source
   -> Parfait pour le web (WordPress, Drupal...)

2. PostgreSQL
   -> Le plus avancé techniquement
   -> Gratuit et open-source
   -> Respect strict des standards SQL

3. SQLite
   -> Base de données EMBARQUÉE (fichier unique)
   -> Parfait pour applications mobiles, desktop
   -> Utilisé par Android, iOS, navigateurs web

4. Oracle Database
   -> Le plus puissant (et le plus cher)
   -> Utilisé par les grandes entreprises

5. Microsoft SQL Server
   -> Intégré à l'écosystème Microsoft
   -> Windows, Azure
"""

# === BASES DE DONNÉES NOSQL ===

"""
┌────────────────────────────────────────────────────────────────────┐
│                BASES DE DONNÉES NOSQL (Not Only SQL)               │
└────────────────────────────────────────────────────────────────────┘

PRINCIPE FONDAMENTAL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Pas de tables, pas de schéma fixe, pas de relations !
-> Données stockées sous forme de DOCUMENTS, CLÉ-VALEUR, GRAPHES, etc.
-> Flexibilité maximale
-> Conçu pour la SCALABILITÉ HORIZONTALE (distribué)


TYPES DE BASES NOSQL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. BASES DOCUMENTAIRES (Document Stores)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-> Données stockées en DOCUMENTS (JSON, BSON, XML)
-> Chaque document peut avoir une structure DIFFÉRENTE
-> Pas besoin de schéma fixe

Exemple : MongoDB

Document client 1 (JSON) :
{
    "_id": "507f1f77bcf86cd799439011",
    "nom": "Jean Dupont",
    "age": 30,
    "email": "jean@example.com",
    "adresse": {
        "rue": "123 Rue de la Paix",
        "ville": "Paris",
        "code_postal": "75001"
    },
    "commandes": [
        {"id": 1, "montant": 150.00, "date": "2024-01-15"},
        {"id": 2, "montant": 220.00, "date": "2024-01-20"}
    ]
}

Document client 2 (structure différente - OK !) :
{
    "_id": "507f1f77bcf86cd799439012",
    "nom": "Marie Martin",
    "email": "marie@example.com",
    "telephone": "+33612345678",
    "preferences": {
        "newsletter": true,
        "categories": ["mode", "beauté"]
    }
    // Pas d'adresse, pas de commandes -> PAS DE PROBLÈME !
}

AVANTAGES :
[OK] Flexibilité totale (pas de schéma fixe)
[OK] Données imbriquées (nested) naturellement
[OK] Très rapide pour la lecture de documents complets
[OK] Scalabilité horizontale facile (sharding)

QUAND UTILISER :
-> Applications avec structure de données variable
-> Prototypage rapide
-> Données hiérarchiques (JSON naturel)
-> Catalogue produits avec attributs variables

EXEMPLES : MongoDB, CouchDB, Couchbase


2. BASES CLÉ-VALEUR (Key-Value Stores)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-> La plus SIMPLE : une CLÉ -> une VALEUR
-> Comme un dictionnaire Python ou HashMap Java
-> Ultra-rapide pour GET/SET

Exemple : Redis

user:1000 -> {"nom": "Jean Dupont", "age": 30}
session:abc123 -> {"user_id": 1000, "expires": "2024-12-31"}
cache:product:42 -> {"nom": "iPhone", "prix": 999}

AVANTAGES :
[OK] Performance MAXIMALE (lecture/écriture en O(1))
[OK] Simplicité extrême
[OK] Parfait pour le cache

INCONVÉNIENTS :
[X] Impossible de faire des requêtes complexes
[X] Pas de recherche par valeur (seulement par clé)

QUAND UTILISER :
-> Cache (sessions, résultats de requêtes)
-> Files d'attente (queues)
-> Compteurs en temps réel
-> Stockage de sessions web

EXEMPLES : Redis, Memcached, DynamoDB (AWS), Riak


3. BASES COLONNES (Column-Family Stores)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-> Données organisées par COLONNES (pas par lignes)
-> Optimisé pour l'analyse de GROS volumes
-> Lecture de colonnes spécifiques ultra-rapide

Exemple : Cassandra, HBase

Au lieu de stocker :
[Jean, 30, Paris] [Marie, 25, Lyon] [Luc, 35, Paris]

On stocke :
noms: [Jean, Marie, Luc]
ages: [30, 25, 35]
villes: [Paris, Lyon, Paris]

AVANTAGES :
[OK] Parfait pour l'analyse (lecture d'une colonne entière)
[OK] Compression très efficace
[OK] Scalabilité massive

QUAND UTILISER :
-> Data warehousing (entrepôts de données)
-> Analytics (Google Analytics utilise BigTable)
-> Logs, métriques en masse
-> Séries temporelles

EXEMPLES : Cassandra, HBase, Google BigTable


4. BASES GRAPHES (Graph Databases)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-> Données stockées en NŒUDS et RELATIONS
-> Optimisé pour les relations complexes (amis, réseaux sociaux)

Exemple : Neo4j

(Jean) --[AMI_DE]--> (Marie)
(Marie) --[AMI_DE]--> (Luc)
(Jean) --[A_ACHETÉ]--> (Produit1)

Requête : "Trouve les amis des amis de Jean qui ont acheté Produit1"
-> TRÈS rapide dans une base graphe
-> TRÈS lent dans une base relationnelle (jointures multiples)

QUAND UTILISER :
-> Réseaux sociaux (Facebook, LinkedIn)
-> Systèmes de recommandation
-> Détection de fraude (réseaux de transactions)
-> Graphes de connaissances

EXEMPLES : Neo4j, OrientDB, ArangoDB


COMPARAISON SQL vs NOSQL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌──────────────────────┬────────────────────┬────────────────────┐
│   Caractéristique    │        SQL         │       NoSQL        │
├──────────────────────┼────────────────────┼────────────────────┤
│ Structure            │ Tables (fixe)      │ Flexible           │
│ Schéma               │ Rigide             │ Dynamique          │
│ Relations            │ Clés étrangères    │ Imbrication/Refs   │
│ Langage              │ SQL (standard)     │ Propriétaire       │
│ Transactions ACID    │ [OK] Oui (complet)  │ [ATTENTION] Limité          │
│ Scalabilité horiz.   │ [ATTENTION] Difficile       │ [OK] Facile          │
│ Performances         │ [RAPIDE] Bonnes (< 10M)  │ [RAPIDE][RAPIDE] Excellentes   │
│ Requêtes complexes   │ [OK] Oui (JOIN)     │ [X] Limitées        │
│ Cohérence            │ [OK] Forte          │ [ATTENTION] Éventuelle     │
│ Courbe apprentissage │ [DOCS] Moyenne        │ [GUIDE] Rapide          │
└──────────────────────┴────────────────────┴────────────────────┘


THÉORÈME CAP (pour NoSQL distribué) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Dans un système distribué, on ne peut avoir que 2 sur 3 :

C = Consistency (Cohérence)
    -> Tous les nœuds voient les mêmes données en même temps

A = Availability (Disponibilité)
    -> Le système répond toujours (même en cas de panne partielle)

P = Partition Tolerance (Tolérance aux partitions)
    -> Le système continue même si le réseau est coupé

SQL classique : CA (Cohérence + Disponibilité, pas de distribution)
MongoDB : CP (Cohérence + Partition, peut être indisponible)
Cassandra : AP (Disponibilité + Partition, cohérence éventuelle)
"""


[OK] PARTIE 3 : MYSQL - LE SGBD WEB PAR EXCELLENCE

"""
┌────────────────────────────────────────────────────────────────────┐
│                        MYSQL EN DÉTAIL                             │
└────────────────────────────────────────────────────────────────────┘

PRÉSENTATION :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[DOLPHIN] Créé en 1995 par MySQL AB (Suède)
[ENTREPRISE] Racheté par Sun Microsystems (2008), puis Oracle (2010)
🆓 Open-source (licence GPL + commerciale)
[MONDE] Base de données relationnelle la plus POPULAIRE au monde
* Utilisé par : Facebook, Twitter, YouTube, Wikipedia, WordPress

POURQUOI "MySQL" ?
-> "My" = prénom de la fille du co-créateur (Michael Widenius)
-> "SQL" = Structured Query Language

Fork : MariaDB (créé par le fondateur original après rachat Oracle)
-> Compatible MySQL, 100% open-source


ARCHITECTURE MYSQL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌────────────────────────────────────────────────────────────────┐
│                       SERVEUR MYSQL                            │
│                                                                │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │              COUCHE CONNEXION (Connection Layer)         │ │
│  │  - Authentification                                      │ │
│  │  - Gestion des threads (un thread par connexion)        │ │
│  │  - Pool de connexions                                   │ │
│  └──────────────────────────────────────────────────────────┘ │
│                              v                                 │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │                 COUCHE SQL (SQL Layer)                   │ │
│  │                                                          │ │
│  │  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐  │ │
│  │  │    Parser    │  │  Optimizer   │  │    Cache     │  │ │
│  │  │  (analyse)   │  │ (optimise)   │  │  (résultats) │  │ │
│  │  └──────────────┘  └──────────────┘  └──────────────┘  │ │
│  └──────────────────────────────────────────────────────────┘ │
│                              v                                 │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │            COUCHE STOCKAGE (Storage Engines)             │ │
│  │                                                          │ │
│  │  ┌────────────┐  ┌────────────┐  ┌────────────┐        │ │
│  │  │   InnoDB   │  │   MyISAM   │  │   Memory   │  ...   │ │
│  │  │ (défaut)   │  │  (ancien)  │  │   (RAM)    │        │ │
│  │  └────────────┘  └────────────┘  └────────────┘        │ │
│  └──────────────────────────────────────────────────────────┘ │
│                              v                                 │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │                   FICHIERS SUR DISQUE                    │ │
│  │  - .ibd (données InnoDB)                                 │ │
│  │  - .frm (structure tables - avant MySQL 8.0)            │ │
│  │  - ib_logfile (redo log)                                │ │
│  │  - binlog (replication log)                             │ │
│  └──────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘


MOTEURS DE STOCKAGE (Storage Engines) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PARTICULARITÉ UNIQUE de MySQL :
-> Possibilité de choisir le MOTEUR de stockage par table !
-> Chaque moteur a ses propres caractéristiques

1. InnoDB (DÉFAUT depuis MySQL 5.5)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[OK] Transactions ACID complètes
[OK] Clés étrangères (FOREIGN KEY)
[OK] Crash recovery (récupération automatique)
[OK] MVCC (Multi-Version Concurrency Control)
[OK] Verrous au niveau ligne (row-level locking)

CREATE TABLE clients (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nom VARCHAR(100)
) ENGINE=InnoDB;

Fichiers créés :
-> clients.ibd (données + index)
-> ib_logfile0, ib_logfile1 (redo log pour crash recovery)

STRUCTURE INTERNE InnoDB :
-> Clustered Index sur PRIMARY KEY
-> Données stockées DANS l'index primaire (B+Tree)
-> Index secondaires pointent vers la clé primaire


2. MyISAM (ANCIEN, déprécié)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[X] PAS de transactions
[X] PAS de clés étrangères
[X] PAS de crash recovery
[OK] Plus rapide pour les lectures pures (SELECT)
[OK] Verrous au niveau table (table-level locking)

CREATE TABLE logs (
    id INT,
    message TEXT
) ENGINE=MyISAM;

Fichiers créés :
-> logs.MYD (données)
-> logs.MYI (index)
-> logs.frm (structure)

NE PLUS UTILISER MYISAM (obsolète) !


3. MEMORY (HEAP)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-> Données stockées en RAM (très rapide [RAPIDE])
-> PERDUES au redémarrage du serveur
-> Idéal pour tables temporaires

CREATE TABLE cache_session (
    session_id VARCHAR(32) PRIMARY KEY,
    data TEXT
) ENGINE=MEMORY;

QUAND UTILISER :
-> Caches temporaires
-> Tables intermédiaires de calcul


4. CSV
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-> Stockage au format CSV (Comma-Separated Values)
-> Fichiers lisibles en texte brut
-> Pas d'index, très lent

QUAND UTILISER :
-> Import/export de données
-> Rarement en production


INSTALLATION MYSQL (LINUX) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# Ubuntu/Debian
sudo apt update
sudo apt install mysql-server

# CentOS/RedHat
sudo yum install mysql-server

# Démarrer le serveur
sudo systemctl start mysql
sudo systemctl enable mysql

# Sécuriser l'installation
sudo mysql_secure_installation

# Se connecter
mysql -u root -p


FICHIERS ET RÉPERTOIRES :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

/var/lib/mysql/              <- Répertoire de données
├── mysql/                   <- Base système (utilisateurs, permissions)
├── performance_schema/      <- Métriques de performance
├── sys/                     <- Vues système (MySQL 5.7+)
├── ecommerce/               <- Une base de données
│   ├── clients.ibd          <- Table clients (InnoDB)
│   ├── commandes.ibd        <- Table commandes
│   └── ...
├── ibdata1                  <- Tablespace système InnoDB
├── ib_logfile0              <- Redo log (crash recovery)
├── ib_logfile1              <- Redo log
├── mysql-bin.000001         <- Binary log (réplication)
├── mysql-bin.index          <- Index des binlogs
└── mysql.sock               <- Socket Unix (connexions locales)

/etc/mysql/
├── my.cnf                   <- Configuration principale
└── mysql.conf.d/
    └── mysqld.cnf           <- Config serveur


CONFIGURATION (my.cnf) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[mysqld]
# Connexions
port = 3306
bind-address = 0.0.0.0              # Écouter toutes interfaces (prudence !)
max_connections = 200               # Connexions simultanées max

# InnoDB
innodb_buffer_pool_size = 2G        # Cache mémoire (75% RAM recommandé)
innodb_log_file_size = 512M         # Taille redo log
innodb_flush_log_at_trx_commit = 1  # 1=sûr, 2=rapide (risque)

# Logs
log_error = /var/log/mysql/error.log
slow_query_log = 1                  # Log requêtes lentes
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2                 # Seuil (secondes)

# Réplication
server-id = 1                       # ID unique du serveur
log_bin = /var/log/mysql/mysql-bin  # Binary log (réplication)

# Charset
character-set-server = utf8mb4      # UTF-8 complet (emojis)
collation-server = utf8mb4_unicode_ci


TYPES DE DONNÉES MYSQL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

NUMÉRIQUES :
TINYINT       : -128 à 127 (1 byte)
SMALLINT      : -32768 à 32767 (2 bytes)
MEDIUMINT     : -8M à 8M (3 bytes)
INT           : -2B à 2B (4 bytes)
BIGINT        : -9 quintillions (8 bytes)
DECIMAL(M,D)  : Nombres décimaux précis (comptabilité)
FLOAT         : Nombres flottants (4 bytes)
DOUBLE        : Nombres flottants double précision (8 bytes)

CHAÎNES :
CHAR(N)       : Taille fixe (rapide, padding espaces)
VARCHAR(N)    : Taille variable (0-65535)
TEXT          : Texte long (0-65535)
MEDIUMTEXT    : Texte très long (0-16M)
LONGTEXT      : Texte énorme (0-4GB)
ENUM('a','b') : Énumération (choix prédéfinis)

DATES/HEURES :
DATE          : Date (YYYY-MM-DD)
TIME          : Heure (HH:MM:SS)
DATETIME      : Date + Heure (1000-9999)
TIMESTAMP     : Timestamp Unix (1970-2038, timezone-aware)
YEAR          : Année (1901-2155)

BINAIRES :
BINARY(N)     : Binaire taille fixe
VARBINARY(N)  : Binaire taille variable
BLOB          : Binary Large Object (fichiers)
MEDIUMBLOB    : Blob moyen (16M)
LONGBLOB      : Blob énorme (4GB)

SPÉCIAUX :
JSON          : Type JSON natif (MySQL 5.7+)
GEOMETRY      : Données géospatiales (points, polygones)


EXEMPLE COMPLET :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

-- Créer une base
CREATE DATABASE ecommerce 
CHARACTER SET utf8mb4 
COLLATE utf8mb4_unicode_ci;

USE ecommerce;

-- Table clients
CREATE TABLE clients (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nom VARCHAR(100) NOT NULL,
    prenom VARCHAR(100),
    email VARCHAR(200) UNIQUE NOT NULL,
    mot_de_passe CHAR(60) NOT NULL,  -- bcrypt hash
    telephone VARCHAR(20),
    date_naissance DATE,
    date_inscription TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    actif BOOLEAN DEFAULT TRUE,
    INDEX idx_email (email),
    INDEX idx_nom (nom, prenom)
) ENGINE=InnoDB;

-- Table adresses
CREATE TABLE adresses (
    id INT PRIMARY KEY AUTO_INCREMENT,
    client_id INT NOT NULL,
    rue VARCHAR(200) NOT NULL,
    ville VARCHAR(100) NOT NULL,
    code_postal VARCHAR(10) NOT NULL,
    pays VARCHAR(50) DEFAULT 'France',
    type ENUM('facturation', 'livraison') NOT NULL,
    FOREIGN KEY (client_id) REFERENCES clients(id) ON DELETE CASCADE,
    INDEX idx_client (client_id)
) ENGINE=InnoDB;

-- Table produits
CREATE TABLE produits (
    id INT PRIMARY KEY AUTO_INCREMENT,
    nom VARCHAR(200) NOT NULL,
    description TEXT,
    prix DECIMAL(10, 2) NOT NULL CHECK (prix >= 0),
    stock INT NOT NULL DEFAULT 0 CHECK (stock >= 0),
    categorie VARCHAR(50),
    image_url VARCHAR(500),
    actif BOOLEAN DEFAULT TRUE,
    date_creation TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    INDEX idx_categorie (categorie),
    INDEX idx_prix (prix),
    FULLTEXT INDEX ft_nom_desc (nom, description)
) ENGINE=InnoDB;

-- Table commandes
CREATE TABLE commandes (
    id INT PRIMARY KEY AUTO_INCREMENT,
    client_id INT NOT NULL,
    adresse_livraison_id INT NOT NULL,
    montant_total DECIMAL(10, 2) NOT NULL,
    statut ENUM('en_attente', 'payée', 'expédiée', 'livrée', 'annulée') 
           DEFAULT 'en_attente',
    date_commande TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    date_paiement TIMESTAMP NULL,
    date_expedition TIMESTAMP NULL,
    FOREIGN KEY (client_id) REFERENCES clients(id),
    FOREIGN KEY (adresse_livraison_id) REFERENCES adresses(id),
    INDEX idx_client (client_id),
    INDEX idx_statut (statut),
    INDEX idx_date (date_commande)
) ENGINE=InnoDB;

-- Table lignes de commande
CREATE TABLE lignes_commande (
    id INT PRIMARY KEY AUTO_INCREMENT,
    commande_id INT NOT NULL,
    produit_id INT NOT NULL,
    quantite INT NOT NULL CHECK (quantite > 0),
    prix_unitaire DECIMAL(10, 2) NOT NULL,
    FOREIGN KEY (commande_id) REFERENCES commandes(id) ON DELETE CASCADE,
    FOREIGN KEY (produit_id) REFERENCES produits(id),
    INDEX idx_commande (commande_id),
    INDEX idx_produit (produit_id)
) ENGINE=InnoDB;

-- Insérer des données
INSERT INTO clients (nom, prenom, email, mot_de_passe, telephone) VALUES
('Dupont', 'Jean', 'jean.dupont@example.com', '$2y$10$...', '+33612345678'),
('Martin', 'Marie', 'marie.martin@example.com', '$2y$10$...', '+33687654321');

INSERT INTO produits (nom, description, prix, stock, categorie) VALUES
('iPhone 15', 'Smartphone Apple dernière génération', 999.00, 50, 'Téléphones'),
('MacBook Pro', 'Ordinateur portable 16 pouces', 2499.00, 20, 'Ordinateurs'),
('AirPods Pro', 'Écouteurs sans fil avec réduction de bruit', 279.00, 100, 'Audio');

-- Requête complexe avec jointures
SELECT 
    c.nom,
    c.prenom,
    co.id AS numero_commande,
    co.date_commande,
    co.montant_total,
    COUNT(lc.id) AS nb_articles,
    GROUP_CONCAT(p.nom SEPARATOR ', ') AS produits
FROM clients c
JOIN commandes co ON c.id = co.client_id
JOIN lignes_commande lc ON co.id = lc.commande_id
JOIN produits p ON lc.produit_id = p.id
WHERE co.statut != 'annulée'
GROUP BY co.id
ORDER BY co.date_commande DESC
LIMIT 10;


AVANTAGES DE MYSQL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[OK] Très populaire (énorme communauté)
[OK] Gratuit et open-source
[OK] Excellent pour applications web
[OK] Performant sur lectures
[OK] Réplication maître-esclave facile
[OK] Intégration parfaite avec PHP, Python, Node.js
[OK] Cloud-friendly (AWS RDS, Google Cloud SQL, Azure)

INCONVÉNIENTS :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[X] Moins de fonctionnalités avancées que PostgreSQL
[X] Respect SQL standard moins strict
[X] Réplication asynchrone par défaut
[X] Certaines fonctionnalités payantes (MySQL Enterprise)
"""


[OK] PARTIE 4 : SQLITE - LA BASE DE DONNÉES EMBARQUÉE

"""
┌────────────────────────────────────────────────────────────────────┐
│                     SQLITE EN DÉTAIL                               │
└────────────────────────────────────────────────────────────────────┘

PRÉSENTATION :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[DOSSIER] Créé en 2000 par D. Richard Hipp
🆓 Domaine public (pas de licence, 100% gratuit)
[RAPIDE] Base de données EMBARQUÉE (pas de serveur !)
[MOBILE] La plus DÉPLOYÉE au monde (milliards d'installations)
* Utilisé par : Android, iOS, Firefox, Chrome, WhatsApp, Skype

PARTICULARITÉ UNIQUE :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
SQLite n'est PAS un serveur client-serveur comme MySQL/PostgreSQL !

MySQL/PostgreSQL :
    Application -> Réseau -> Serveur MySQL
    (processus séparé, port 3306/5432)

SQLite :
    Application -> Bibliothèque SQLite -> Fichier .db
    (pas de serveur, juste une bibliothèque C)

TOUT DANS UN FICHIER :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-> Base de données complète = UN SEUL FICHIER
-> ecommerce.db (contient tout : tables, index, données)
-> Facile à copier, déplacer, sauvegarder
-> Parfait pour applications desktop, mobile, IoT


ARCHITECTURE SQLITE :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌────────────────────────────────────────────────────────────────┐
│                    APPLICATION                                 │
│  (Python, Java, C++, JavaScript, etc.)                         │
└────────────────────────────────────────────────────────────────┘
                         v API SQLite (sqlite3)
┌────────────────────────────────────────────────────────────────┐
│                 BIBLIOTHÈQUE SQLITE (libsqlite3)               │
│                                                                │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │              INTERFACE SQL (SQL Command Processor)       │ │
│  │  - Analyse (Parser)                                      │ │
│  │  - Tokenizer (découpage)                                 │ │
│  └──────────────────────────────────────────────────────────┘ │
│                         v                                      │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │            CODE GENERATOR (Bytecode Generator)           │ │
│  │  - Génère du bytecode pour la Virtual Machine            │ │
│  └──────────────────────────────────────────────────────────┘ │
│                         v                                      │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │        VIRTUAL MACHINE (VDBE - Virtual Database Engine)  │ │
│  │  - Exécute le bytecode                                   │ │
│  │  - Accès aux données via B-Tree                          │ │
│  └──────────────────────────────────────────────────────────┘ │
│                         v                                      │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │                B-TREE MODULE                             │ │
│  │  - Gestion des arbres B                                  │ │
│  │  - Curseurs pour parcourir les données                   │ │
│  └──────────────────────────────────────────────────────────┘ │
│                         v                                      │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │                PAGER (Page Cache)                        │ │
│  │  - Cache des pages (1KB, 4KB, 8KB...)                   │ │
│  │  - Gestion transactions                                  │ │
│  │  - Journalisation (rollback journal)                     │ │
│  └──────────────────────────────────────────────────────────┘ │
│                         v                                      │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │                OS INTERFACE (VFS)                        │ │
│  │  - Abstraction système de fichiers                       │ │
│  │  - Portabilité (Windows, Linux, macOS, etc.)            │ │
│  └──────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘
                         v
┌────────────────────────────────────────────────────────────────┐
│                  FICHIER SQLITE (.db, .sqlite)                 │
│                                                                │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │  Page 1: Database Header (100 bytes)                    │ │
│  │  - Magic: "SQLite format 3"                              │ │
│  │  - Taille de page (512, 1024, 4096, 8192...)            │ │
│  │  - Encoding (UTF-8, UTF-16)                              │ │
│  │  - Schema cookie                                         │ │
│  └──────────────────────────────────────────────────────────┘ │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │  Page 2-N: Table B-Trees                                │ │
│  │  - Données des tables                                    │ │
│  └──────────────────────────────────────────────────────────┘ │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │  Page M-P: Index B-Trees                                │ │
│  │  - Index pour accélération                               │ │
│  └──────────────────────────────────────────────────────────┘ │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │  Freelist: Pages libres                                 │ │
│  │  - Réutilisables après DELETE                            │ │
│  └──────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘

Fichiers additionnels (temporaires) :
ecommerce.db-journal    <- Rollback journal (transactions)
ecommerce.db-wal        <- Write-Ahead Log (mode WAL)
ecommerce.db-shm        <- Shared Memory (mode WAL)


INSTALLATION ET UTILISATION :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

LIGNE DE COMMANDE :
# Installation (déjà inclus dans la plupart des OS)
# Ubuntu/Debian
sudo apt install sqlite3

# Utilisation
sqlite3 ecommerce.db

SQLite version 3.37.2
Enter ".help" for usage hints.
sqlite> 

# Commandes spéciales (commencent par .)
.tables              # Lister les tables
.schema clients      # Voir la structure d'une table
.mode column         # Affichage en colonnes
.headers on          # Afficher les en-têtes
.output results.txt  # Rediriger la sortie
.quit                # Quitter


PYTHON (intégré par défaut) :
import sqlite3

# Connexion (crée le fichier si inexistant)
conn = sqlite3.connect('ecommerce.db')
cursor = conn.cursor()

# Créer une table
cursor.execute('''
CREATE TABLE IF NOT EXISTS clients (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    nom TEXT NOT NULL,
    email TEXT UNIQUE NOT NULL,
    age INTEGER CHECK(age >= 0)
)
''')

# Insérer des données
cursor.execute('''
INSERT INTO clients (nom, email, age)
VALUES (?, ?, ?)
''', ('Jean Dupont', 'jean@example.com', 30))

# Valider
conn.commit()

# Lire des données
cursor.execute('SELECT * FROM clients WHERE age > ?', (25,))
for row in cursor.fetchall():
    print(row)

# Fermer
conn.close()


JAVASCRIPT (Node.js avec better-sqlite3) :
const Database = require('better-sqlite3');
const db = new Database('ecommerce.db');

// Créer table
db.exec(`
    CREATE TABLE IF NOT EXISTS clients (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        nom TEXT NOT NULL,
        email TEXT UNIQUE NOT NULL
    )
`);

// Préparer statement (plus rapide)
const insert = db.prepare('INSERT INTO clients (nom, email) VALUES (?, ?)');
insert.run('Jean Dupont', 'jean@example.com');

// Lire
const select = db.prepare('SELECT * FROM clients WHERE nom = ?');
const results = select.all('Jean Dupont');
console.log(results);

db.close();


TYPES DE DONNÉES SQLITE :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PARTICULARITÉ : SQLite a seulement 5 types de stockage !

INTEGER    : Entiers (1, 2, 3, 4, 6, ou 8 bytes selon la valeur)
REAL       : Flottants (8 bytes)
TEXT       : Chaînes UTF-8 ou UTF-16
BLOB       : Binaire (tel quel)
NULL       : Valeur nulle

TYPAGE DYNAMIQUE :
-> Tu peux déclarer VARCHAR(100), DATE, BOOLEAN...
-> Mais SQLite les convertit en INTEGER, TEXT, etc.
-> Tu peux même stocker différents types dans la même colonne !

CREATE TABLE exemple (
    id INTEGER PRIMARY KEY,
    valeur TEXT
);

INSERT INTO exemple VALUES (1, 'texte');        -- OK
INSERT INTO exemple VALUES (2, 123);            -- OK aussi !
INSERT INTO exemple VALUES (3, 3.14);           -- OK aussi !
INSERT INTO exemple VALUES (4, x'DEADBEEF');    -- BLOB, OK !

C'est le "duck typing" des bases de données !


TRANSACTIONS ET JOURNALISATION :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

MODES DE JOURNALISATION :

1. DELETE (défaut) - Rollback Journal
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
BEGIN TRANSACTION;
    UPDATE clients SET age = 31 WHERE id = 1;
    -- Avant modification, pages originales copiées dans .db-journal
    -- En cas de crash : restauration depuis .db-journal
COMMIT;

Fichier créé : ecommerce.db-journal
Supprimé après COMMIT réussi


2. WAL (Write-Ahead Logging) - RECOMMANDÉ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
PRAGMA journal_mode=WAL;

Avantages :
[OK] Lectures et écritures CONCURRENTES
[OK] Plus rapide (moins de fsync)
[OK] Plus robuste

Inconvénient :
[X] Fichiers additionnels (.db-wal, .db-shm)

Fichiers créés :
ecommerce.db-wal    <- Write-Ahead Log (modifications)
ecommerce.db-shm    <- Shared Memory (index du WAL)


NIVEAUX D'ISOLATION :
PRAGMA read_uncommitted = 0;  # READ COMMITTED (défaut)
PRAGMA read_uncommitted = 1;  # READ UNCOMMITTED


OPTIMISATIONS SQLITE :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

-- Mode WAL (concurrent reads/writes)
PRAGMA journal_mode = WAL;

-- Cache size (nombre de pages en RAM)
PRAGMA cache_size = -64000;  # 64 MB (valeur négative = KB)

-- Synchronisation (durabilité vs performance)
PRAGMA synchronous = NORMAL;  # FULL (sûr) | NORMAL | OFF (risqué)

-- Taille de page
PRAGMA page_size = 4096;  # 1024, 2048, 4096, 8192, 16384, 32768

-- Analyse automatique
PRAGMA analysis_limit = 400;
PRAGMA optimize;

-- Vacuum (récupérer espace après DELETE)
VACUUM;  # Réorganise et compacte le fichier


INDEX ET PERFORMANCES :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

-- Créer index
CREATE INDEX idx_clients_email ON clients(email);
CREATE INDEX idx_clients_nom_age ON clients(nom, age);

-- Index unique (comme UNIQUE constraint)
CREATE UNIQUE INDEX idx_clients_email_unique ON clients(email);

-- Analyser performances
EXPLAIN QUERY PLAN SELECT * FROM clients WHERE email = 'jean@example.com';

Sans index :
SCAN TABLE clients

Avec index :
SEARCH TABLE clients USING INDEX idx_clients_email (email=?)


LIMITATIONS DE SQLITE :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[X] Un seul ÉCRIVAIN à la fois (mais plusieurs lecteurs en WAL)
[X] Pas de gestion utilisateurs / permissions
[X] Pas de procédures stockées
[X] ALTER TABLE très limité
[X] Pas de RIGHT JOIN, FULL OUTER JOIN
[X] Taille fichier limitée (281 TB en théorie, mais < 1 TB recommandé)
[X] Pas adapté aux applications web avec beaucoup d'écritures simultanées


AVANTAGES DE SQLITE :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[OK] ZÉRO configuration (pas de serveur à installer)
[OK] UN SEUL fichier (facile à distribuer, sauvegarder)
[OK] TRÈS rapide pour lectures
[OK] Faible empreinte mémoire (<500 KB)
[OK] Transactions ACID complètes
[OK] Gratuit, domaine public
[OK] Multiplateforme (Windows, Linux, macOS, Android, iOS...)
[OK] TRÈS fiable (tests exhaustifs)
[OK] Idéal pour prototypage rapide


QUAND UTILISER SQLITE ?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[OK] Applications DESKTOP (Electron, Qt, .NET)
[OK] Applications MOBILES (Android, iOS)
[OK] Applications EMBARQUÉES (IoT, routeurs, TV...)
[OK] TESTS unitaires (base temporaire rapide)
[OK] PROTOTYPAGE (avant migration vers MySQL/PostgreSQL)
[OK] Stockage LOCAL dans le navigateur (via WASM)
[OK] Petites applications WEB (< 100 utilisateurs concurrents)
[OK] Cache LOCAL, configuration d'application
[OK] Analyse de DONNÉES locales

NE PAS UTILISER SQLITE pour :
[X] Site web haute concurrence (> 100k req/jour en écriture)
[X] Gros volumes (> 1 TB)
[X] Réseau (SQLite n'est pas fait pour ça)
[X] Besoins de permissions utilisateurs complexes
"""


[OK] PARTIE 5 : POSTGRESQL - LE SGBD OPEN-SOURCE LE PLUS AVANCÉ

"""
┌────────────────────────────────────────────────────────────────────┐
│                   POSTGRESQL EN DÉTAIL                             │
└────────────────────────────────────────────────────────────────────┘

PRÉSENTATION :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[POSTGRES] Créé en 1986 (projet POSTGRES à Berkeley)
🆓 100% open-source (licence PostgreSQL, très permissive)
[CROWN] "The world's most advanced open source database"
* Utilisé par : Instagram, Spotify, Reddit, Apple, Uber, Netflix

POURQUOI PostgreSQL EST DIFFÉRENT :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[OK] RESPECT STRICT DES STANDARDS SQL (ANSI SQL:2016)
[OK] EXTENSIBILITÉ : tu peux créer tes propres types, fonctions, opérateurs
[OK] TYPES AVANCÉS : JSON, XML, Arrays, Range, Geometric, Network...
[OK] INDEX AVANCÉS : B-Tree, Hash, GiST, GiN, BRIN, Bloom
[OK] MVCC (Multi-Version Concurrency Control) sans verrous lecteurs
[OK] FULL-TEXT SEARCH natif (comme Elasticsearch light)
[OK] RÉPLICATION : streaming, logique, pub/sub
[OK] PARTITIONNEMENT natif (depuis PG10)
[OK] PARALLEL QUERIES (requêtes parallélisées)
[OK] JIT (Just-In-Time Compilation) pour performance (PG11+)


ARCHITECTURE (voir document Oracle/PostgreSQL déjà fourni) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-> Modèle PROCESSUS (pas threads comme MySQL)
-> Postmaster : processus principal
-> Backend : un processus par connexion
-> Shared Memory : cache partagé (Shared Buffers)
-> WAL (Write-Ahead Log) : journalisation


TYPES DE DONNÉES POSTGRESQL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

NUMÉRIQUES :
SMALLINT, INTEGER, BIGINT
DECIMAL, NUMERIC (précision arbitraire)
REAL, DOUBLE PRECISION
SERIAL, BIGSERIAL (auto-incrémentation)
MONEY (monétaire avec 2 décimales)

CHAÎNES :
CHAR(N), VARCHAR(N), TEXT (illimité)
"char" (1 byte interne PostgreSQL)

DATES/HEURES :
DATE, TIME, TIME WITH TIME ZONE
TIMESTAMP, TIMESTAMP WITH TIME ZONE
INTERVAL (durée)

BOOLÉENS :
BOOLEAN (TRUE, FALSE, NULL)

BINAIRES :
BYTEA (binaire variable)

GÉOMÉTRIQUES :
POINT, LINE, LSEG, BOX, PATH, POLYGON, CIRCLE

RÉSEAU :
INET (IPv4/IPv6)
CIDR (réseau IP)
MACADDR, MACADDR8 (adresse MAC)

UUID :
UUID (identifiant universel unique)

JSON/XML :
JSON, JSONB (binaire, plus rapide)
XML

TABLEAUX :
INTEGER[] (tableau d'entiers)
TEXT[] (tableau de chaînes)
ANYARRAY (tableau générique)

RANGES (intervalles) :
INT4RANGE, INT8RANGE
TSRANGE, TSTZRANGE (timestamps)
DATERANGE

ENUM :
CREATE TYPE mood AS ENUM ('happy', 'sad', 'ok');

TYPES COMPOSITES (comme structs) :
CREATE TYPE address AS (
    street TEXT,
    city TEXT,
    postal_code TEXT
);


FONCTIONNALITÉS AVANCÉES :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. JSON/JSONB (Document NoSQL dans PostgreSQL !)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CREATE TABLE produits (
    id SERIAL PRIMARY KEY,
    nom TEXT,
    metadata JSONB  -- JSONB = JSON binaire (plus rapide)
);

INSERT INTO produits (nom, metadata) VALUES
('iPhone', '{"couleur": "noir", "stockage": "256GB", "prix": 999}'),
('MacBook', '{"couleur": "argent", "RAM": "16GB", "prix": 2499}');

-- Requêtes JSON
SELECT nom, metadata->>'couleur' AS couleur
FROM produits
WHERE (metadata->>'prix')::INT > 1000;

-- Index sur JSON
CREATE INDEX idx_metadata_prix ON produits USING GIN ((metadata->'prix'));

-- Opérateurs JSON
-> : extraire objet JSON
->> : extraire texte
#> : chemin JSON
@> : contient
? : clé existe


2. FULL-TEXT SEARCH (Recherche textuelle)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CREATE TABLE articles (
    id SERIAL PRIMARY KEY,
    titre TEXT,
    contenu TEXT,
    ts_vector TSVECTOR  -- Vecteur de recherche
);

-- Générer vecteur de recherche
UPDATE articles SET ts_vector = 
    to_tsvector('french', titre || ' ' || contenu);

-- Index GIN pour recherche rapide
CREATE INDEX idx_fts ON articles USING GIN(ts_vector);

-- Rechercher
SELECT titre, ts_rank(ts_vector, query) AS rank
FROM articles, to_tsquery('french', 'PostgreSQL & base') AS query
WHERE ts_vector @@ query
ORDER BY rank DESC;


3. WINDOW FUNCTIONS (Fonctions fenêtre)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

-- Ranking
SELECT 
    nom,
    salaire,
    RANK() OVER (ORDER BY salaire DESC) AS rang,
    ROW_NUMBER() OVER (ORDER BY salaire DESC) AS numero
FROM employes;

-- Moyenne glissante
SELECT 
    date,
    ventes,
    AVG(ventes) OVER (
        ORDER BY date 
        ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
    ) AS moyenne_7_jours
FROM ventes_journalieres;


4. CTE (Common Table Expressions) et RECURSIVE
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

-- CTE simple
WITH meilleurs_clients AS (
    SELECT client_id, SUM(montant) AS total
    FROM commandes
    GROUP BY client_id
    HAVING SUM(montant) > 10000
)
SELECT c.nom, mc.total
FROM meilleurs_clients mc
JOIN clients c ON c.id = mc.client_id;

-- CTE RECURSIVE (hiérarchies)
WITH RECURSIVE sous_categories AS (
    -- Ancre : catégories racines
    SELECT id, nom, parent_id, 0 AS niveau
    FROM categories
    WHERE parent_id IS NULL
    
    UNION ALL
    
    -- Récursion : sous-catégories
    SELECT c.id, c.nom, c.parent_id, sc.niveau + 1
    FROM categories c
    JOIN sous_categories sc ON c.parent_id = sc.id
)
SELECT * FROM sous_categories ORDER BY niveau, nom;


5. EXTENSIONS (Extensibilité)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

-- Activer extension
CREATE EXTENSION IF NOT EXISTS "uuid-ossp";
CREATE EXTENSION IF NOT EXISTS "pg_trgm";  -- Trigrams (similarité)
CREATE EXTENSION IF NOT EXISTS "postgis";   -- Données géospatiales

-- Générer UUID
SELECT uuid_generate_v4();

-- Similarité de texte (typos)
SELECT nom, similarity(nom, 'Jhon') AS sim
FROM clients
WHERE nom % 'Jhon'  -- Opérateur similarité
ORDER BY sim DESC;


6. PARTITIONNEMENT
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

-- Partitionnement par plage (dates)
CREATE TABLE ventes (
    id SERIAL,
    date DATE NOT NULL,
    montant DECIMAL(10,2)
) PARTITION BY RANGE (date);

-- Partitions
CREATE TABLE ventes_2023 PARTITION OF ventes
    FOR VALUES FROM ('2023-01-01') TO ('2024-01-01');

CREATE TABLE ventes_2024 PARTITION OF ventes
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

-- Insertion automatique dans la bonne partition
INSERT INTO ventes (date, montant) VALUES ('2024-06-15', 150.00);


EXEMPLE COMPLET AVEC TYPES AVANCÉS :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

CREATE TABLE utilisateurs (
    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    email TEXT UNIQUE NOT NULL,
    mot_de_passe TEXT NOT NULL,
    profil JSONB,
    tags TEXT[],  -- Tableau
    derniere_connexion TIMESTAMP WITH TIME ZONE,
    actif BOOLEAN DEFAULT TRUE,
    adresse INET,  -- Adresse IP
    plage_age INT4RANGE,  -- Ex: [18, 65)
    recherche TSVECTOR  -- Full-text search
);

CREATE INDEX idx_profil_gin ON utilisateurs USING GIN (profil);
CREATE INDEX idx_tags_gin ON utilisateurs USING GIN (tags);
CREATE INDEX idx_recherche ON utilisateurs USING GIN (recherche);

INSERT INTO utilisateurs (email, mot_de_passe, profil, tags, plage_age) VALUES
('jean@example.com', 'hash...', 
 '{"nom": "Jean Dupont", "ville": "Paris", "interets": ["tech", "sport"]}',
 ARRAY['premium', 'early_adopter'],
 '[25, 35)');

-- Requête complexe
SELECT 
    email,
    profil->>'nom' AS nom,
    array_to_string(tags, ', ') AS tags_str
FROM utilisateurs
WHERE profil @> '{"ville": "Paris"}'  -- Contient ville Paris
  AND 'premium' = ANY(tags)            -- Tag premium
  AND plage_age @> 30                  -- Âge dans la plage
  AND actif = TRUE;


AVANTAGES DE POSTGRESQL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[OK] Le PLUS conforme aux standards SQL
[OK] Fonctionnalités les plus AVANCÉES (JSON, full-text, arrays...)
[OK] MVCC sans verrous lecteurs (très performant en concurrence)
[OK] EXTENSIBLE (types, fonctions, index personnalisés)
[OK] TRÈS fiable (ACID strict, crash recovery robuste)
[OK] Excellente documentation
[OK] Communauté active et bienveillante
[OK] Gratuit, open-source, aucune restriction
[OK] Supporte NoSQL (JSONB) + SQL dans la même base !

INCONVÉNIENTS :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[X] Courbe d'apprentissage plus raide
[X] Configuration optimale plus complexe
[X] VACUUM nécessaire (tuples morts avec MVCC)
[X] Moins connu que MySQL (moins de ressources en ligne)
"""


[OK] PARTIE 6 : MONGODB - LA BASE DE DONNÉES NOSQL DOCUMENTAIRE

"""
┌────────────────────────────────────────────────────────────────────┐
│                      MONGODB EN DÉTAIL                             │
└────────────────────────────────────────────────────────────────────┘

PRÉSENTATION :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[LEAF_FLUTTERING_IN_WIND] Créé en 2007 par 10gen (devenu MongoDB Inc.)
🆓 Open-source (Server Side Public License) + Commercial
[FICHIER] Base de données DOCUMENTAIRE (JSON/BSON)
[MONDE] NoSQL le plus populaire
* Utilisé par : Uber, eBay, Adobe, Forbes, Cisco

POURQUOI "MongoDB" ?
-> "humongous" (énorme en anglais) -> Mongo
-> Conçu pour stocker d'ÉNORMES volumes de données

DIFFÉRENCE FONDAMENTALE AVEC SQL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

SQL (MySQL/PostgreSQL) :
-> TABLES avec lignes et colonnes
-> Schéma FIXE
-> Relations via FOREIGN KEYS
-> Jointures avec JOIN

MongoDB :
-> COLLECTIONS de DOCUMENTS (JSON/BSON)
-> Schéma FLEXIBLE (chaque document peut être différent)
-> Pas de relations strictes (imbrication ou références)
-> Pas de jointures classiques (aggregation pipeline)


ARCHITECTURE MONGODB :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌────────────────────────────────────────────────────────────────┐
│                      SERVEUR MONGODB                           │
│                                                                │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │                   MONGOD (Daemon)                        │ │
│  │  - Processus principal                                   │ │
│  │  - Écoute port 27017 par défaut                          │ │
│  └──────────────────────────────────────────────────────────┘ │
│                         v                                      │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │              QUERY ROUTER (Routeur de requêtes)          │ │
│  │  - Parse les requêtes                                    │ │
│  │  - Optimisation                                          │ │
│  └──────────────────────────────────────────────────────────┘ │
│                         v                                      │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │                  STORAGE ENGINE                          │ │
│  │                                                          │ │
│  │  ┌──────────────┐  ┌──────────────┐                     │ │
│  │  │  WiredTiger  │  │   MMAPv1     │  (ancien)           │ │
│  │  │   (défaut)   │  │  (déprécié)  │                     │ │
│  │  └──────────────┘  └──────────────┘                     │ │
│  └──────────────────────────────────────────────────────────┘ │
│                         v                                      │
│  ┌──────────────────────────────────────────────────────────┐ │
│  │                  FICHIERS DISQUE                         │ │
│  │  - .wt (WiredTiger data files)                           │ │
│  │  - journal/ (Write-Ahead Log)                            │ │
│  │  - _mdb_catalog.wt (catalog)                             │ │
│  └──────────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────────┘


CONCEPTS MONGODB :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DATABASE (Base de données)
    v
COLLECTION (≈ TABLE SQL)
    v
DOCUMENT (≈ LIGNE SQL, format BSON)
    v
FIELD (≈ COLONNE SQL)

Exemple :

Database: ecommerce
    Collection: clients
        Document 1:
        {
            "_id": ObjectId("507f1f77bcf86cd799439011"),
            "nom": "Jean Dupont",
            "email": "jean@example.com",
            "age": 30,
            "adresse": {
                "rue": "123 Rue de la Paix",
                "ville": "Paris",
                "code_postal": "75001"
            },
            "commandes": [
                {
                    "id": 1,
                    "date": ISODate("2024-01-15"),
                    "montant": 150.00
                },
                {
                    "id": 2,
                    "date": ISODate("2024-01-20"),
                    "montant": 220.00
                }
            ],
            "tags": ["premium", "vip"]
        }
        
        Document 2:  (STRUCTURE DIFFÉRENTE - OK !)
        {
            "_id": ObjectId("507f1f77bcf86cd799439012"),
            "nom": "Marie Martin",
            "email": "marie@example.com",
            "telephone": "+33612345678"
            // Pas d'adresse, pas de commandes -> PAS DE PROBLÈME !
        }


TYPES DE DONNÉES BSON :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

String         : "texte"
Integer        : 32 ou 64 bits
Double         : 64 bits flottant
Boolean        : true / false
Date           : ISODate("2024-01-15T10:30:00Z")
Null           : null
Array          : ["a", "b", "c"]
Object         : {clé: "valeur"}
ObjectId       : ObjectId("507f1f77...")  (ID unique 12 bytes)
Binary         : Données binaires
Regular Expr   : /pattern/flags
JavaScript     : Code JS (rarement utilisé)
Timestamp      : Timestamp(1234567890, 1)
Decimal128     : Haute précision (finance)


INSTALLATION :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

# Ubuntu/Debian
wget -qO - https://www.mongodb.org/static/pgp/server-7.0.asc | sudo apt-key add -
echo "deb [ arch=amd64,arm64 ] https://repo.mongodb.org/apt/ubuntu jammy/mongodb-org/7.0 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-7.0.list
sudo apt update
sudo apt install mongodb-org

# Démarrer
sudo systemctl start mongod
sudo systemctl enable mongod

# Client shell
mongosh


UTILISATION (mongosh) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

// Voir les bases
show dbs

// Utiliser/créer une base
use ecommerce

// Voir les collections
show collections

// CRÉER (pas de schéma nécessaire !)
db.clients.insertOne({
    nom: "Jean Dupont",
    email: "jean@example.com",
    age: 30,
    adresse: {
        ville: "Paris",
        code_postal: "75001"
    },
    tags: ["premium"]
})

// CRÉER plusieurs
db.clients.insertMany([
    {nom: "Marie", email: "marie@example.com", age: 25},
    {nom: "Luc", email: "luc@example.com", age: 35}
])

// LIRE
db.clients.find()  // Tous
db.clients.find({age: {$gt: 25}})  // Age > 25
db.clients.find({tags: "premium"})  // Contient tag
db.clients.findOne({email: "jean@example.com"})

// Projection (sélectionner champs)
db.clients.find({}, {nom: 1, email: 1, _id: 0})

// MODIFIER
db.clients.updateOne(
    {email: "jean@example.com"},  // Filtre
    {$set: {age: 31, ville: "Lyon"}}  // Modifications
)

// Ajouter élément à tableau
db.clients.updateOne(
    {email: "jean@example.com"},
    {$push: {tags: "vip"}}
)

// Incrémenter
db.clients.updateOne(
    {email: "jean@example.com"},
    {$inc: {age: 1}}  // age += 1
)

// SUPPRIMER
db.clients.deleteOne({email: "jean@example.com"})
db.clients.deleteMany({age: {$lt: 18}})  // Age < 18


OPÉRATEURS DE REQUÊTE :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

COMPARAISON :
$eq   : égal
$ne   : différent
$gt   : plus grand que
$gte  : plus grand ou égal
$lt   : plus petit que
$lte  : plus petit ou égal
$in   : dans liste
$nin  : pas dans liste

// Exemples
db.clients.find({age: {$gte: 18, $lte: 65}})
db.produits.find({categorie: {$in: ["electronique", "informatique"]}})

LOGIQUES :
$and  : ET
$or   : OU
$not  : NON
$nor  : NI

// Exemple
db.clients.find({
    $or: [
        {age: {$lt: 18}},
        {age: {$gt: 65}}
    ]
})

ÉLÉMENTS :
$exists : champ existe
$type   : type du champ

// Exemples
db.clients.find({telephone: {$exists: true}})
db.clients.find({age: {$type: "int"}})

TABLEAUX :
$all   : contient tous les éléments
$size  : taille tableau
$elemMatch : élément correspondant

// Exemples
db.clients.find({tags: {$all: ["premium", "vip"]}})
db.clients.find({commandes: {$size: 3}})


AGRÉGATION (Aggregation Pipeline) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

// Équivalent SQL GROUP BY
db.commandes.aggregate([
    // Stage 1: Filtrer (WHERE)
    {$match: {statut: "payée"}},
    
    // Stage 2: Grouper (GROUP BY)
    {$group: {
        _id: "$client_id",
        total: {$sum: "$montant"},
        nombre: {$count: {}}
    }},
    
    // Stage 3: Filtrer groupes (HAVING)
    {$match: {total: {$gt: 1000}}},
    
    // Stage 4: Trier (ORDER BY)
    {$sort: {total: -1}},
    
    // Stage 5: Limiter (LIMIT)
    {$limit: 10}
])

// Jointure (lookup = LEFT JOIN)
db.commandes.aggregate([
    {$lookup: {
        from: "clients",
        localField: "client_id",
        foreignField: "_id",
        as: "client_info"
    }},
    {$unwind: "$client_info"},  // Déplie tableau
    {$project: {
        _id: 1,
        montant: 1,
        "client_info.nom": 1,
        "client_info.email": 1
    }}
])


INDEX MONGODB :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

// Index simple
db.clients.createIndex({email: 1})  // 1 = ascendant, -1 = descendant

// Index composé
db.clients.createIndex({nom: 1, prenom: 1})

// Index unique
db.clients.createIndex({email: 1}, {unique: true})

// Index sur champ imbriqué
db.clients.createIndex({"adresse.ville": 1})

// Index sur tableau
db.clients.createIndex({tags: 1})

// Index texte (full-text search)
db.articles.createIndex({contenu: "text"})
db.articles.find({$text: {$search: "MongoDB NoSQL"}})

// Index géospatial
db.restaurants.createIndex({location: "2dsphere"})
db.restaurants.find({
    location: {
        $near: {
            $geometry: {type: "Point", coordinates: [2.3522, 48.8566]},  // Paris
            $maxDistance: 5000  // 5 km
        }
    }
})

// Voir les index
db.clients.getIndexes()

// Analyser performance
db.clients.find({email: "jean@example.com"}).explain("executionStats")


TRANSACTIONS (depuis MongoDB 4.0) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

const session = db.getMongo().startSession()
session.startTransaction()

try {
    db.comptes.updateOne(
        {_id: 1},
        {$inc: {solde: -100}},
        {session}
    )
    
    db.comptes.updateOne(
        {_id: 2},
        {$inc: {solde: 100}},
        {session}
    )
    
    session.commitTransaction()
} catch (error) {
    session.abortTransaction()
    throw error
} finally {
    session.endSession()
}


RÉPLICATION (Replica Set) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

MongoDB utilise la réplication MASTER-SLAVE :
-> PRIMARY : nœud principal (lectures + écritures)
-> SECONDARY : nœuds secondaires (réplicas, lectures optionnelles)
-> ARBITER : vote en cas d'élection (pas de données)

Élection automatique si le PRIMARY tombe !


SHARDING (Distribution horizontale) :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Partitionnement automatique sur plusieurs serveurs :
-> Shard Key : champ utilisé pour distribuer
-> Exemple : clients shardés par pays

// Enable sharding
sh.enableSharding("ecommerce")
sh.shardCollection("ecommerce.clients", {pays: 1})


AVANTAGES DE MONGODB :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[OK] FLEXIBILITÉ totale (pas de schéma fixe)
[OK] Très RAPIDE pour lectures/écritures simples
[OK] SCALABILITÉ horizontale facile (sharding)
[OK] Format JSON naturel (parfait pour JavaScript/Node.js)
[OK] Requêtes riches (aggregation pipeline)
[OK] Réplication automatique
[OK] Bon pour prototypage rapide
[OK] Index puissants (géospatiaux, texte...)

INCONVÉNIENTS :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
[X] Pas de JOINS natifs (aggregation pipeline moins performant)
[X] Transactions ACID limitées (depuis 4.0 seulement)
[X] Consomme plus de mémoire
[X] Duplication des données (dénormalisation)
[X] Pas idéal pour données très relationnelles
[X] Licence SSPL controversée


QUAND UTILISER MONGODB ?
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

[OK] Applications avec structure de données VARIABLE
[OK] Prototypage RAPIDE (pas besoin de définir schéma)
[OK] Catalogue de PRODUITS (attributs différents par catégorie)
[OK] Logs, événements, métriques
[OK] Applications TEMPS RÉEL (gaming, chat)
[OK] Big Data, Analytics
[OK] Mobile (synchronisation hors-ligne)
[OK] CMS (Content Management System)

NE PAS UTILISER MongoDB pour :
[X] Applications FINANCIÈRES (banque, comptabilité)
   -> Besoin de transactions ACID strictes
[X] Données fortement RELATIONNELLES
   -> Nombreuses jointures -> SQL plus efficace
[X] Rapports complexes avec agrégations lourdes
   -> SQL + data warehouse plus adapté
"""


[OK] PARTIE 7 : COMPARAISONS DÉTAILLÉES

"""
┌────────────────────────────────────────────────────────────────────┐
│          COMPARAISON COMPLÈTE : MySQL vs PostgreSQL vs             │
│                      SQLite vs MongoDB                             │
└────────────────────────────────────────────────────────────────────┘

TABLEAU COMPARATIF GLOBAL :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

┌───────────────────┬─────────────┬──────────────┬─────────────┬─────────────┐
│ Caractéristique   │   MySQL     │  PostgreSQL  │   SQLite    │   MongoDB   │
├───────────────────┼─────────────┼──────────────┼─────────────┼─────────────┤
│ Type              │ SQL         │ SQL          │ SQL         │ NoSQL       │
│ Modèle            │ Client-     │ Client-      │ Embarqué    │ Client-     │
│                   │ Serveur     │ Serveur      │ (fichier)   │ Serveur     │
│ Licence           │ GPL + comm. │ PostgreSQL   │ Domaine     │ SSPL +      │
│                   │             │ (permissive) │ public      │ commercial  │
│ Création          │ 1995        │ 1996         │ 2000        │ 2007        │
│ Langage           │ C/C++       │ C            │ C           │ C++         │
│ Populaire pour    │ Web (PHP)   │ Enterprise   │ Mobile,     │ Big Data,   │
│                   │             │              │ Desktop     │ Temps réel  │
├───────────────────┼─────────────┼──────────────┼─────────────┼─────────────┤
│ ACID              │ [OK] (InnoDB) │ [OK]           │ [OK]          │ [ATTENTION] (limité)│
│ Transactions      │ [OK]          │ [OK]           │ [OK]          │ [ATTENTION] (v4.0+) │
│ Schéma rigide     │ [OK]          │ [OK]           │ [OK]          │ [X]          │
│ Clés étrangères   │ [OK] (InnoDB) │ [OK]           │ [OK]          │ [X]          │
│ Jointures         │ [OK]          │ [OK]           │ [OK]          │ [ATTENTION] (lookup)│
│ Full-text search  │ [ATTENTION] (basique)│ [OK] Avancé    │ [ATTENTION] (FTS5)   │ [OK] Avancé   │
│ JSON              │ [ATTENTION] (limité) │ [OK] JSONB     │ [ATTENTION] (texte)  │ [OK] Natif    │
│ Arrays            │ [X]          │ [OK]           │ [X]          │ [OK]          │
├───────────────────┼─────────────┼──────────────┼─────────────┼─────────────┤
│ Scalabilité horiz.│ [ATTENTION]          │ [ATTENTION]           │ [X]          │ [OK]          │
│ Performance       │ [RAPIDE][RAPIDE][RAPIDE]     │ [RAPIDE][RAPIDE][RAPIDE]      │ [RAPIDE][RAPIDE][RAPIDE][RAPIDE]   │ [RAPIDE][RAPIDE][RAPIDE]      │
│ Facilité          │ ***     │ **        │ ****   │ ****  │
│ Maturité          │ *****│ ***** │ ***** │ ***     │
└───────────────────┴─────────────┴──────────────┴─────────────┴─────────────┘

Pour voir le détail complet des comparaisons, voyage des requêtes et guide de décision,
consultez les sections 7, 8 et 9 du guide complet.
"""


[OK] RÉCAPITULATIF FINAL

"""
┌────────────────────────────────────────────────────────────────────┐
│                    CE QUE TU AS APPRIS                             │
└────────────────────────────────────────────────────────────────────┘

[OK] BASES DE DONNÉES : Le couteau suisse du stockage de données
   -> Organisation, performance, cohérence, concurrence, durabilité

[OK] SQL vs NoSQL : Deux philosophies
   -> SQL : Structure rigide, relations, ACID strict
   -> NoSQL : Flexibilité, scalabilité, schéma dynamique

[OK] MYSQL : Le champion du web
   -> Populaire, fiable, parfait pour applications web classiques

[OK] SQLITE : L'embarqué léger
   -> Un seul fichier, zéro configuration, parfait pour mobile/desktop

[OK] POSTGRESQL : L'outil puissant pour cas complexes
   -> Types avancés, extensibilité, respect des standards

[OK] MONGODB : La flexibilité NoSQL
   -> Documents JSON, scalabilité horizontale, prototypage rapide

[OK] ARCHITECTURE : Comment ça marche sous le capot
   -> Parser -> Optimiseur -> Moteur de stockage -> Fichiers disque

[OK] PERFORMANCE : Index, cache, optimisation
   -> Index B-Tree accélèrent les recherches
   -> Cache mémoire évite les accès disque
   -> Statistiques guident l'optimiseur

[OK] CHOIX : Quelle base pour quel projet ?
   -> Mobile/Desktop -> SQLite
   -> Web relationnel -> MySQL/PostgreSQL
   -> Flexibilité/Big Data -> MongoDB


PROCHAINES ÉTAPES :
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. PRATIQUE : Installe et teste chaque SGBD
2. PROJETS : Crée une petite application avec chacun
3. PERFORMANCE : Benchmark, mesure, optimise
4. AVANCÉ : Réplication, sharding, haute disponibilité
5. SÉCURITÉ : Authentification, chiffrement, sauvegardes

Maintenant, TU MAÎTRISES les bases de données ! [COURS][RAPIDE]
De la théorie à la pratique, des fondamentaux aux choix d'architecture.
Tu es prêt pour construire des applications robustes et scalables ! [RAPIDE]
"""

# FIN DU GUIDE