Quand pas de SQL

Prérequis : cours précédents + 4.1 (modélisation à venir).

Pourquoi

« Quelle base choisir ? » précède « SQL ou NoSQL ? » : la vraie question, c'est la forme des données et des requêtes. Choisir NoSQL par hype pour des données relationnelles = payer le relationnel sans l'avoir.

Concepts

• Document (Mongo…) : JSON flexible, bien pour catalogues hétérogènes et prototypage. Mal pour : jointures (à faire à la main !), transactions multi-documents (limitées), schéma qui « n'existe pas » (il existe, implicite et non vérifié — pire).
• Clé-valeur / colonnes / graphe : KV (Redis : simple et vite), wide-column (Cassandra/Scylla : écritures massives séries temporelles), graphe (Neo4j : relations complexes — reco, fraude, réseaux).
• Test de décision : relations + intégrité + requêtes ad hoc → SQL. Volume d'écriture extrême + requêtes connues → wide-column. Relations AU CŒUR du métier → graphe. Cache/temps réel → KV.

Exemple : se tromper coûte combien ?

Catalogue e-commerce en Mongo « pour la flexibilité » : 2 ans plus tard, 40 % du code = jointures manuelles + contrôles d'intégrité réinventés (mal). Migration Postgres/JSONB : flexible ET relationnel. Règle : Postgres d'abord (JSONB couvre 90 % du « flexible »), NoSQL sur besoin prouvé.

Cas réel

Séries IoT en Postgres (1M de points/jour) : table de 2 ans = 700M de lignes, VACUUM impossible, requêtes lentes. Migration TimescaleDB (hypertables) : compression ×10, requêtes ×100. Le besoin (séries temporelles massives) appelait wide-column/TSDB dès le début.

Pièges

• « Schemaless » = sans schéma : faux, le schéma est implicite, dispersé dans le code, non vérifié. Pire des mondes.
• Choisir avant de mesurer : le besoin prouvé (volume, forme, requêtes) décide, pas la hype.
• Polyglot persistance sans équipe : 4 bases = 4 sauvegardes, 4 monitorings, 4 compétences. Chaque base se paie en ops.

À retenir

Postgres d'abord (JSONB), NoSQL sur besoin prouvé ; schéma implicite = pire ; chaque base se paie en ops.