Tablas, filas y claves

El índice está abierto. QUERY despliega sobre la mesa de trabajo un holograma: miles de registros quedan suspendidos en el aire formando una rejilla ordenada, y entre algunos de ellos se tienden finos hilos color ámbar. Tiras de uno y suena como la cuerda de un instrumento. Esto no es un montón de archivos. Es un tejido.

Tablas, filas, columnas

Una base relacional se parece a un catálogo ordenado: los datos se reparten en tablas, y dentro de cada tabla hay columnas (qué propiedades guardamos) y filas (los registros concretos).

Fíjate en la tabla de clientes users: cada fila es un cliente de la antigua Tierra, y las columnas describen su id, full_name, email, country, city, signup_date.

Para no confundir a personas con el mismo nombre, cada fila tiene una clave primaria (primary key): un identificador único, normalmente la columna id. Gracias a ella, otras tablas pueden referirse a esa fila mediante una clave foránea (foreign key). Por ejemplo, un pedido en orders guarda un user_id: así el pedido recuerda quién lo hizo. Esos hilos color ámbar del holograma son precisamente los vínculos por claves.

QUERY: Mientras la clave aguante, el hilo aguanta. Siglo y medio después, cada pedido todavía recuerda a su persona.

Lanza la consulta y observa qué aspecto tienen los clientes de «Kotomarket»: registros que nadie había abierto desde los tiempos de la antigua Red:

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:

Clave natural o subrogada

¿De dónde sale una clave primaria? Hay dos caminos. Una clave natural es un atributo real que ya es único por sí mismo: el email de un cliente, el ISBN de un libro, el código de una moneda. Una clave subrogada es un identificador artificial sin significado fuera de la base: un número autogenerado o un UUID. En «Kotomarket» se usan id subrogados en todas partes, y es una decisión de manual:

-- Clave subrogada: la base reparte ella misma el siguiente número (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- el candidato natural vive al lado como UNIQUE
  full_name TEXT NOT NULL
);

¿Por qué hacerlo así? La regla de oro de una clave primaria es que no debe cambiar. A la PK apuntan las claves foráneas de otras tablas, y cambiar su valor obligaría a actualizar todos los hilos a la vez: en orders, en events, en todas partes. Y casi no existen atributos naturales «eternos»: la gente cambia de email y de apellido, los teléfonos se reasignan, incluso los ISBN se reeditan. Un id subrogado no cambia nunca precisamente porque no significa nada.

Requisitos de cualquier clave primaria: única, no NULL, estable. Deja las claves naturales para tablas de referencia pequeñas e inmutables, por ejemplo el código de moneda 'RUB' de la ISO 4217. Y garantiza la unicidad de un candidato natural como email con una restricción UNIQUE aparte, como en el ejemplo de arriba: los vínculos se mantienen, los datos siguen siendo honestos y al cliente no se le prohíbe cambiar de correo.