Le schéma de « Kotomarket »

Aujourd'hui, QUERY fait apparaître tout l'index d'un coup au-dessus de la table principale. Cinq plans lumineux flottent dans l'air et tournent lentement — la carte du monde qui a survécu. À côté scintille le journal de conservation joint à l'instantané, avec une ligne soulignée : « Je transmets cinq tables et la trace d'une sixième. — K. » Tu comptes les plans. Exactement cinq. Où est la trace ?

QUERY : Ne te laisse pas distraire par les traces. Apprends d'abord à connaître ces cinq-là au point de retrouver ton chemin les yeux fermés — l'archive te montrera le reste d'elle-même quand elle te jugera prêt.

Les cinq tables de « Kotomarket »

À partir d'ici, nous travaillerons avec cette base — l'instantané d'une boutique en ligne de l'année 2024. Pense-la comme le plan du magasin : qui est entré, ce qui était en vitrine, ce qui a été acheté et quelles actions ont précédé l'achat.

Les liens se lisent ainsi : un user → plusieurs orders ; une order → plusieurs order_items ; un product → plusieurs order_items. Si tu te perds, ouvre le schéma à droite — c'est le plan de la surface de vente.

Jetons un œil à la table des commandes : chaque ligne possède un user_id — une référence vers un acheteur. C'est ainsi qu'une table se relie à une autre, et la carte cesse d'être composée de cinq îlots séparés.

Kotomarket’s five tables

From here on we’ll be working with this database — a snapshot of an online shop from 2024. Hold it like a map of the store: who walked in, what’s on the shelves, what they bought, and what they did before buying.

The links read like this: one user → many orders; one order → many order_items; one product → many order_items. If you get lost, open the schema on the right — it’s like the floor plan of the shop.

Let’s peek into the orders table: every row has a user_id — a reference to a buyer. That’s how one table links to another, and the map stops being five separate islands.

Comment lire un diagramme ER

La carte que QUERY a déroulée porte, dans l'industrie, le nom de diagramme ER (entity–relationship) : les rectangles sont des tables, les lignes entre eux sont des liens par clés étrangères. Le plus important sur une ligne, c'est sa cardinalité : combien de lignes d'un côté peuvent correspondre à combien de lignes de l'autre.

• 1:N, un-à-plusieurs — le lien le plus fréquent. Un acheteur, plusieurs commandes. La clé étrangère se trouve toujours du côté « plusieurs » : user_id est stocké dans orders, et non l'inverse. C'est la règle de lecture : tu as trouvé la FK, tu as trouvé le côté N.
• N:M, plusieurs-à-plusieurs — une commande contient plusieurs produits, et un produit peut se retrouver dans plusieurs commandes. Un tel lien ne peut pas s'exprimer directement dans une base relationnelle : la clé étrangère n'a nulle part où aller. On le déploie via une table intermédiaire — chez nous, c'est order_items. Chacune de ses lignes porte une paire de références order_id + product_id et transforme un lien N:M en deux liens 1:N. Mieux : le lien lui-même reçoit ses attributs — la quantité et le prix au moment de l'achat.
• 1:1, un-à-un — plus rare : on extrait par exemple des champs volumineux ou privés vers une table séparée portant la même clé.

-- La résolution N:M en action : les paires « commande — produit » depuis order_items
SELECT order_id, product_id, quantity
FROM order_items
LIMIT 6;