Tables, lignes et clés

L'index est ouvert. QUERY déploie un hologramme au-dessus du bureau : des milliers d'enregistrements flottent dans l'air en grille régulière, et de fins fils ambrés courent entre certains d'entre eux. Tu tends la main vers l'un de ces fils — il vibre comme une corde. Ce n'est pas un tas de fichiers. C'est une trame.

Tables, lignes, colonnes

Une base relationnelle ressemble à un catalogue bien rangé : les données sont réparties en tables, et chaque table contient des colonnes (les propriétés que l'on stocke) et des lignes (les enregistrements individuels).

Prends la table des acheteurs users : chaque ligne correspond à un acheteur de la vieille Terre, et les colonnes décrivent son id, son full_name, son email, son country, sa city, sa signup_date.

Pour ne pas confondre deux personnes portant le même nom, chaque ligne possède une clé primaire (primary key) — un identifiant unique, en général la colonne id. Grâce à elle, d'autres tables peuvent référencer cette ligne au moyen d'une clé étrangère (foreign key). Par exemple, une commande de orders possède un user_id — c'est ainsi que la commande se souvient de son acheteur. Les fils ambrés sur l'hologramme, ce sont précisément ces liens par clés.

QUERY : Tant que la clé tient, le fil tient. Un siècle et demi a passé, et chaque commande se souvient encore de sa personne.

Lance la requête et regarde à quoi ressemblent les acheteurs de « Kotomarket » — des enregistrements que personne n'avait ouverts depuis l'époque de l'ancien Réseau :

Tables, rows, columns

A relational database is like a tidy catalog: the data is sorted into tables, and inside each table there are columns (what properties we store) and rows (the individual records).

Take the buyers’ table users: each row is one buyer from old Earth, and the columns describe their id, full_name, email, country, city, signup_date.

So that people with the same name don’t get confused, every row has a primary key — a unique identifier, usually the id column. Through it, other tables can reference this row using a foreign key. For example, an order in orders has a user_id — that’s how an order remembers its buyer. Those amber threads on the hologram are exactly these key-based links.

QUERY: As long as the key holds, the thread holds. A century and a half on, every order still remembers its person.

Run the query and see what Kotomarket’s buyers look like — records no one has opened since the days of the old Net:

Clé naturelle ou clé de substitution

D'où vient une clé primaire ? Il y a deux possibilités. Une clé naturelle est un attribut réel déjà unique : l'email d'un acheteur, l'ISBN d'un livre, un code de devise. Une clé de substitution est un identifiant artificiel sans signification dans le monde réel : une numérotation automatique ou un UUID. « Kotomarket » utilise partout des id de substitution — c'est un choix classique :

-- Clé de substitution : la base attribue elle-même le numéro suivant (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- le candidat naturel vit à côté en tant que UNIQUE
  full_name TEXT NOT NULL
);

Pourquoi ce choix ? La propriété essentielle d'une clé primaire, c'est qu'elle ne doit pas changer. Les clés étrangères des autres tables pointent vers la clé primaire, et changer sa valeur obligerait à mettre à jour tous les fils d'un coup — dans orders, dans events, partout. Or les attributs naturels vraiment « éternels » sont rares : les gens changent d'email et de nom de famille, les numéros de téléphone sont réattribués, même les ISBN connaissent des rééditions. Un id de substitution ne change jamais — justement parce qu'il ne signifie rien.

Toute clé primaire doit être unique, non NULL et stable. Réserve les clés naturelles aux petites tables de référence immuables — par exemple le code de devise 'RUB' de la norme ISO 4217. Et pour garantir l'unicité d'un candidat naturel comme email, utilise une contrainte UNIQUE distincte, comme dans l'exemple ci-dessus : les liens restent stables, les données restent fiables, et rien n'empêche l'acheteur de changer son adresse e-mail.