Les différents types de bases de données

En chemin vers l'index, QUERY ralentit devant une section sombre du coffre. Derrière la vitre : le registre des archives de la vieille Terre qui n'ont pas survécu au Grand Effondrement. Les nœuds de cache se sont éteints les premiers, les stockages documentaires ne sont arrivés qu'en fragments, les grappes analytiques restent muettes sur des secteurs entiers. L'instantané relationnel de « Kotomarket », lui, a survécu en entier — tous ses liens intacts.

Pas seulement les relationnelles

Pour « Kotomarket », les BD relationnelles conviennent particulièrement bien : acheteurs, commandes et produits se rangent naturellement dans des tables reliées entre elles. C'est à elles que ce cours est consacré. Mais dans l'industrie, on rencontre aussi d'autres approches :

• clé-valeur (Redis) — un format « clé → valeur » très rapide, quand il faut retrouver instantanément un enregistrement simple ;
• orientées documents (MongoDB) — elles stockent des documents JSON flexibles, dont la structure peut varier d'un enregistrement à l'autre ;
• en colonnes (ClickHouse) — très efficaces pour l'analyse, quand il faut calculer rapidement des indicateurs sur d'énormes volumes de données.

La plupart des SGBD utilisés pour développer des applications restent relationnels : PostgreSQL, MySQL, Oracle, MS SQL. Maîtrise le SQL ici, et tu sauras lire des données avec assurance dans des entreprises très différentes.

QUERY : À chaque archive son travail : à l'une la vitesse, à l'autre la souplesse, à la troisième l'analyse. Toi et moi avons eu de la chance : nous avons hérité de celle où tout est relié à tout.

Not only relational

For Kotomarket, relational databases suit us especially well: buyers, orders, and products fall naturally into tables with links between them. That’s what this course is about. But across the industry — in 2024 just as today — you’ll meet other approaches too:

• key-value (Redis) — a blazingly fast "key → value" format for when you need to grab a simple record instantly;
• document-oriented (MongoDB) — stores flexible JSON documents whose structure can differ from record to record;
• columnar (ClickHouse) — strong at analytics, when you need to crunch metrics over enormous volumes of data fast.

Most of the popular DBMSs for product development stay relational: PostgreSQL, MySQL, Oracle, MS SQL. Master SQL here and you’ll be able to read data confidently at very different companies.

QUERY: Each archive has its own job: one prizes speed, another flexibility, a third analytics. You and I got lucky: we inherited the one where everything is connected to everything.

Le registre des familles : un classement en bonne et due forme

Le registre derrière la vitre est une bonne occasion d'aborder sérieusement les familles de bases de données : « quels types de BD existent et quand utiliser laquelle ? » est l'une des questions d'entretien les plus fréquentes. Parcourons cinq familles, toujours selon le même modèle : mode de stockage, forces et faiblesses, produits et cas d'usage.

BD relationnelles : schéma strict et liens

Mode de stockage : des lignes dans des tables dont le schéma est déclaré à l'avance — chaque colonne a un type, des liens par clés relient les tables, et le SGBD veille lui-même à l'intégrité : impossible d'enregistrer une commande pour un acheteur qui n'existe pas. Les modifications sont exécutées dans des transactions avec des garanties ACID — « la commande + le décompte du stock » sont écrits ensemble, ou pas du tout.

• Forces : un SQL expressif (filtres, jointures de tables, agrégats), une intégrité garantie au niveau de la base, des transactions.
• Faiblesses : le schéma doit être pensé à l'avance et migré quand il évolue ; la mise à l'échelle horizontale sur de nombreux serveurs est plus délicate que pour les familles NoSQL.
• Produits : PostgreSQL, MySQL/MariaDB, Microsoft SQL Server, Oracle, SQLite.
• Quand la choisir : utilisateurs, commandes, argent, stock — partout où les données sont liées et où une mauvaise écriture coûte cher. Pour un nouveau produit, c'est le choix par défaut.

Bases clé-valeur : un dictionnaire à pleine vitesse

Mode de stockage : un immense dictionnaire « clé → valeur », le plus souvent en mémoire vive. Pas de tables, pas de liens : tu écris par clé, tu relis par clé en une fraction de milliseconde.

-- Ce n'est pas du SQL, ce sont des commandes Redis
SET session:8f3a '{"user_id": 42}'
GET session:8f3a

• Forces : la vitesse, la simplicité, une mise à l'échelle facile.
• Faiblesses : on ne peut interroger que par clé exacte — impossible de demander à ce format « trouve toutes les sessions des acheteurs de Moscou » ; pour la base, l'intérieur d'une valeur est opaque.
• Produits : Redis, Memcached, Amazon DynamoDB.
• Quand la choisir : cache, sessions, compteurs, files d'attente, classements — des données chaudes à côté de la base principale, pas à sa place.

BD documentaires : du JSON flexible

Mode de stockage : les enregistrements sont des documents JSON regroupés en collections. Le schéma n'est pas déclaré à l'avance : une montre connectée a un champ « autonomie de la batterie », un sweat à capuche a un « guide des tailles », et les deux documents cohabitent sans problème dans une même collection. Les structures imbriquées sont stockées directement dans le document, sans tables séparées.

• Forces : une structure flexible, un document lu en entier en un seul accès, un modèle pratique pour les catalogues aux attributs hétérogènes et les prototypes rapides.
• Faiblesses : les liens entre documents relèvent de l'application, il n'y a presque pas de véritable JOIN ; sans discipline, une collection devient vite un fourre-tout de formats incompatibles.
• Produits : MongoDB, Couchbase, Firestore.
• Quand la choisir : contenu, catalogues aux champs très variables, profils et réglages.

La frontière entre familles est d'ailleurs floue : PostgreSQL sait stocker des documents dans une colonne de type jsonb et y construire des index — souvent, cela suffit à couvrir un besoin « documentaire » sans seconde base :

-- Un exemple hors de notre instantané : attrs est une colonne de type jsonb
SELECT name, attrs->>'color' AS color
FROM catalog
WHERE attrs @> '{"brand": "Kotomarket"}';

BD en colonnes : de l'analyse sur des milliards de lignes

Mode de stockage : les valeurs ne sont pas rangées ligne par ligne, mais colonne par colonne : tous les prix ensemble, toutes les dates ensemble. Une requête « panier moyen par mois » ne lit sur le disque que deux colonnes au lieu de toute la table, et des valeurs de même nature se compressent très bien. C'est ce qui rend les agrégats si rapides.

-- Le genre favori d'une base en colonnes (dialecte ClickHouse : toYYYYMM est sa fonction)
SELECT toYYYYMM(created_at) AS month, avg(total_amount) AS avg_check
FROM orders
GROUP BY month;

• Forces : les agrégats, le balayage de milliards de lignes, une forte compression.
• Faiblesses : les mises à jour et suppressions ponctuelles coûtent cher ; lire une ligne entière est plus lent que dans une base en lignes ; elles ne sont tout simplement pas conçues pour la charge transactionnelle.
• Produits : ClickHouse, BigQuery, Snowflake, Amazon Redshift.
• Quand la choisir : analyse, rapports, événements, journaux, métriques — généralement à côté de la base relationnelle « de production ».

Profitons-en pour clarifier deux termes que les recruteurs adorent : OLTP (online transaction processing — beaucoup d'opérations courtes d'écriture et de lecture, le monde de PostgreSQL) et OLAP (online analytical processing — de lourdes lectures analytiques sur tout l'historique, le monde de ClickHouse). L'application écrit dans la base OLTP, les outils d'analyse lisent une copie OLAP.

Et une dernière famille — les BD graphes

Quand les liens comptent plus que les enregistrements eux-mêmes — « les amis des amis », les itinéraires de livraison, les chaînes de recommandation — on choisit des BD graphes (Neo4j, Memgraph). Les données y sont des nœuds (les enregistrements) et des arêtes (les liens entre enregistrements) ; parcourir des liens à n'importe quelle profondeur est une opération native. Dans une base relationnelle, le même parcours devient une succession de jointures de tables qui s'alourdit à mesure que la profondeur augmente.

Mini-guide : comment choisir une base pour un projet

1. Pars des questions, pas des données. Quelles requêtes l'application va-t-elle poser : ponctuelles « par clé », relationnelles « qui a acheté quoi », analytiques « combien sur le mois » ?
2. Par défaut — relationnelle. Des données liées et un coût d'erreur élevé (commandes, paiements, stocks) — c'est PostgreSQL. C'est le point de départ le plus sûr pour presque n'importe quel projet.
3. Les bases spécialisées répondent à une tâche précise, pas à un besoin « au cas où ». Les lectures les plus fréquentes saturent — ajoute un cache sur Redis. L'analyse a grossi — réplique les événements vers ClickHouse. Les champs varient énormément — commence par jsonb dans PostgreSQL, et ne passe à une base documentaire que si cela ne suffit plus.
4. Compte le coût d'une seconde base. Chaque nouveau SGBD implique de la synchronisation de données, des sauvegardes, de la supervision et une technologie de plus à maintenir pour l'équipe.