Tabelas, linhas e chaves

O índice está aberto. QUERY desdobra um holograma sobre a mesa de trabalho: milhares de registros pairam no ar em uma grade regular, e fios finos de luz âmbar correm entre alguns deles. Você estende a mão para um fio — ele vibra como uma corda. Isto não é um monte de arquivos. É um tecido.

Tabelas, linhas, colunas

Um banco de dados relacional é como um catálogo bem-organizado: os dados ficam distribuídos em tabelas, e dentro de cada tabela há colunas (as propriedades que guardamos) e linhas (os registros individuais).

Pegue a tabela de compradores users: cada linha é um comprador da velha Terra, e as colunas descrevem seu id, full_name, email, country, city, signup_date.

Para não confundir pessoas com o mesmo nome, cada linha tem uma chave primária (primary key) — um identificador único, normalmente a coluna id. Por meio dela, outras tabelas conseguem apontar para essa linha usando uma chave estrangeira (foreign key). Por exemplo, um pedido em orders tem um user_id — é assim que o pedido se lembra de quem comprou. Aqueles fios âmbar no holograma são exatamente essas conexões por chaves.

QUERY: Enquanto a chave estiver intacta, o fio está intacto. Um século e meio depois, cada pedido ainda sabe de quem é.

Execute a consulta e veja como são os compradores do «Kotomarket» — registros que ninguém abria desde os tempos da velha Rede:

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:

Chave natural ou substituta

De onde vem uma chave primária? Há dois caminhos. Uma chave natural é um atributo real que já é único: o email de um comprador, o ISBN de um livro, um código de moeda. Uma chave substituta é um identificador artificial, sem significado no mundo externo: uma autonumeração ou um UUID. No «Kotomarket», usam-se id substitutos em tudo — uma escolha clássica:

-- Chave substituta: o banco mesmo entrega o próximo número (PostgreSQL)
CREATE TABLE users (
  id        BIGINT GENERATED ALWAYS AS IDENTITY PRIMARY KEY,
  email     TEXT NOT NULL UNIQUE,  -- o candidato natural vive ao lado como UNIQUE
  full_name TEXT NOT NULL
);

Por quê? Porque a propriedade fundamental de uma chave primária é: ela não deve mudar. As chaves estrangeiras de outras tabelas apontam para a PK, e alterar esse valor obrigaria a atualizar todos os fios de uma vez — em orders, em events, em todo lugar. E atributos naturais «eternos» quase não existem: as pessoas mudam de email e de sobrenome, números de telefone são reaproveitados, até ISBNs são reeditados. Um id substituto nunca muda — justamente porque não significa nada.

Requisitos para qualquer chave primária: única, não NULL, estável. Deixe as chaves naturais para tabelas de referência pequenas e imutáveis — o código de moeda 'RUB' da ISO 4217, por exemplo. E a unicidade de um candidato natural como email você garante com uma restrição UNIQUE à parte, como no exemplo acima: as conexões se mantêm, os dados continuam consistentes, e o comprador ainda pode trocar de email.