Base de données et SGBD : qui fait quoi ?

Chapitre 1 — « La carte de l'archive »

L'instantané de « Kotomarket » n'est plus un signal perdu venu d'un secteur mort : il repose dans un sas de quarantaine de la station Vault-9, et sous la dernière ligne de son dump figure toujours la même signature : « K. ». Ce matin, une nouvelle entrée s'allume sur ton holopanneau : « Habilitation : index de l'archive. Délivrée par : module S.Q.L. » La porte du coffre coulisse sur le côté ; derrière elle, dans une lueur ambrée, des baies de serveurs ronronnent à un rythme régulier.

QUERY : Avant de lire la mémoire de quelqu'un d'autre, comprends comment elle est construite. Commençons par l'essentiel : ici, qu'est-ce qui stocke les données, et qui les garde ?

Base de données et SGBD

Une base de données (BD) est un espace de stockage organisé. L'instantané de « Kotomarket » contient des acheteurs, des produits, des commandes et des événements : pas des fichiers éparpillés, mais une structure claire. C'est précisément pour cela qu'on peut encore les lire cent soixante ans plus tard.

Mais le stockage, à lui seul, ne répond pas aux questions. Il faut un programme capable de créer des tables, d'enregistrer de nouvelles commandes, de lire les données et de veiller à ce que les liens ne se rompent jamais. Ce programme, c'est le SGBD (système de gestion de base de données). Exemples : PostgreSQL, MySQL, ClickHouse. Notre instantané est une base PostgreSQL, et elle parle encore le même SQL qu'à l'époque où la boutique tournait.

Tu écris une requête en SQL → tu l'envoies au SGBD → le SGBD va chercher les données demandées et renvoie le résultat. Excel est parfait pour un tableur personnel, mais il n'est pas fait pour une boutique où des milliers d'utilisateurs consultent des produits, passent des commandes et laissent des événements dans le système, tous au même moment.

Database and DBMS

A database is an organized store. The Kotomarket snapshot holds buyers, products, orders, and events — not scattered across files, but in a clear structure. That’s exactly why it can still be read a hundred and sixty years later.

But the store itself doesn’t answer questions. You need a program that can create tables, record new orders, read data, and make sure the links never break. That’s a DBMS (database management system). Examples: PostgreSQL, MySQL, ClickHouse. Our snapshot is a PostgreSQL database, and it still speaks the same SQL it did when the shop was alive.

You write a query in SQL → send it to the DBMS → the DBMS fetches the data you asked for and returns the result. Excel is fine for a personal spreadsheet, but not for a shop where thousands of users browse products, place orders, and leave events in the system all at once.

Ce qu'un SGBD sait faire, contrairement à de « simples fichiers »

À première vue, la boutique pourrait vivre sans SGBD : il suffirait d'écrire les commandes dans un CSV ou un fichier Excel. À l'échelle d'un carnet personnel, c'est exactement ce qu'on fait — jusqu'au moment où apparaissent les problèmes pour lesquels le SGBD a été inventé.

• Accès concurrent. Dans le « Kotomarket » vivant, les acheteurs passaient leurs commandes en même temps. Deux processus qui écrivent dans le même fichier risquent d'écraser mutuellement leurs modifications ; un SGBD exécute les modifications sous forme de transactions et coordonne les opérations parallèles. PostgreSQL le fait grâce au mécanisme MVCC : les lecteurs ne bloquent pas les écritures, et inversement.
• Récupération après panne. L'alimentation clignote au milieu d'une écriture : le fichier est corrompu, et impossible de savoir quelle moitié de la commande a été enregistrée. Le SGBD inscrit d'abord la modification dans un journal (sous PostgreSQL, le WAL — write-ahead log), puis la rejoue après la panne : la commande est soit enregistrée en entier, soit pas du tout.
• Contrôle d'accès. Un fichier est ouvert en entier, ou pas ouvert du tout. Dans un SGBD, les droits sont granulaires — jusqu'à une table précise :

-- L'analyste : lecture seule des commandes, sans droit de les modifier
GRANT SELECT ON orders TO analyst;

• Intégrité. Un SGBD n'acceptera pas une commande dont le prix est du texte, ni une référence vers un acheteur qui n'existe pas : les types des colonnes et les contraintes sont vérifiés à chaque écriture. Un fichier, lui, ne se préoccupe pas de ce qu'il contient.
• Questions déclaratives. « Montre-moi les commandes de plus de 5000 » tient en une ligne de SQL. Avec un fichier, il faudrait écrire un programme pour faire le même travail — et l'écrire sans erreur.