SQL ou NoSQL ?

SQL ou NoSQL ? Une base relationnelle range ses données dans des tables liées par des clés et s'interroge en SQL. Les bases NoSQL suivent d'autres modèles : clé-valeur, documents, colonnes larges, graphes. Ce chapitre t'aide à choisir, compare un ticket de la base d'exemple parc à un document MongoDB et montre les colonnes JSON de MySQL.

Les familles de bases de données

Le modèle relationnel n'est pas le seul. Depuis les années 2000, d'autres familles, regroupées sous le nom NoSQL (not only SQL), répondent à des besoins particuliers.

Quand choisir une base orientée documents

Dans MongoDB, un ticket et ses interventions pourraient tenir dans un seul document :

{
  "_id": 9,
  "titre": "Rançongiciel suspecté",
  "priorite": "critique",
  "statut": "resolu",
  "demandeur": { "id": 7, "nom": "Faure", "service": "Logistique" },
  "interventions": [
    { "technicien": "Mercier", "date": "2026-10-05T08:20:00", "duree_min": 240 },
    { "technicien": "Diallo",  "date": "2026-10-05T13:30:00", "duree_min": 180 },
    { "technicien": "Lambert", "date": "2026-10-06T09:00:00", "duree_min": 150 }
  ]
}

Lire le ticket complet ne demande plus aucune jointure, et un ticket peut porter des champs qu'un autre n'a pas. En contrepartie, le nom du service est recopié dans chaque ticket : si la Logistique change de nom, tous ses documents sont à modifier, et rien ne garantit que demandeur.id correspond à un employé existant. On retrouve les anomalies du tableur.

Un modèle document convient quand les données sont lues comme un tout, avec une structure qui varie, et peu de liens entre entités. Un modèle relationnel convient quand les données sont fortement liées, partagées entre plusieurs usages, et que leur cohérence compte. Pour un parc et un helpdesk, le relationnel reste le bon choix. Le cours MongoDB et API Node.js montre MongoDB en pratique.

Les colonnes JSON dans MySQL

MySQL offre un compromis : le type JSON stocke un document validé dans une colonne d'une table relationnelle. Les caractéristiques techniques varient d'un modèle de poste à l'autre ; plutôt que d'ajouter une colonne par caractéristique, on les range dans un document :

ALTER TABLE poste ADD COLUMN caracteristiques JSON;

UPDATE poste
SET caracteristiques = '{"ram_go": 16, "ssd_go": 512, "ecran_pouces": 14}'
WHERE id_poste = 12;

UPDATE poste
SET caracteristiques = JSON_OBJECT('ram_go', 8, 'ssd_go', 256)
WHERE id_poste = 7;

SELECT num_inventaire,
       caracteristiques->>'$.ram_go' AS ram_go,
       JSON_EXTRACT(caracteristiques, '$.ssd_go') AS ssd_go
FROM poste
WHERE caracteristiques->'$.ram_go' >= 16;

-> extrait une valeur JSON, ->> l'extrait et retire les guillemets d'une chaîne. Un JSON invalide est refusé à l'insertion. Garde les colonnes JSON pour des attributs secondaires et variables : ce qui sert à joindre, à filtrer souvent ou à contraindre mérite une vraie colonne.

Cohérence et disponibilité : le théorème CAP

Quand une base est répartie sur plusieurs serveurs, une coupure réseau peut les séparer. Le théorème CAP dit qu'en cas de partition réseau (P), un système doit choisir entre la cohérence (C : tous les nœuds renvoient la même donnée, quitte à refuser de répondre) et la disponibilité (A : chaque nœud répond, quitte à renvoyer une donnée pas encore à jour).

Un SGBD relationnel en réplication synchrone privilégie la cohérence ; beaucoup de bases NoSQL réparties, comme Cassandra, privilégient la disponibilité et parlent de cohérence à terme (eventual consistency) : les nœuds finissent par converger. Pour un solde bancaire ou un stock de licences, on veut la cohérence ; pour le compteur de vues d'une vidéo, une valeur légèrement en retard est acceptable.

Exercices

SELECT num_inventaire, caracteristiques->>'$.ssd_go' AS ssd_go
FROM poste
WHERE caracteristiques IS NOT NULL
ORDER BY CAST(caracteristiques->>'$.ssd_go' AS UNSIGNED) DESC;

SELECT JSON_OBJECT(
         'id', t.id_ticket,
         'titre', t.titre,
         'demandeur', dem.nom,
         'interventions', JSON_ARRAYAGG(
             JSON_OBJECT('technicien', tech.nom, 'duree_min', i.duree_min))
       ) AS document
FROM ticket t
JOIN employe dem      ON dem.id_employe = t.id_demandeur
JOIN intervention i   ON i.id_ticket = t.id_ticket
JOIN employe tech     ON tech.id_employe = i.id_technicien
WHERE t.id_ticket = 9
GROUP BY t.id_ticket, t.titre, dem.nom;