BD e SGBD: quem faz o quê

Capítulo 1 — «O mapa do arquivo»

O instantâneo do «Kotomarket» já não é um sinal vindo de um setor morto — está num compartimento de quarentena a bordo da estação Vault-9, e abaixo da última linha do dump continua a mesma assinatura: «K.». Esta manhã, um novo registro pisca no seu holopainel: «Acesso liberado: o índice do arquivo. Emitido por: módulo S.Q.L.» A porta do cofre desliza para o lado; atrás dela, sob uma luz âmbar, os racks de servidores zumbem sem parar.

QUERY: Antes de ler a memória de outra pessoa, entenda como ela foi construída. Vamos começar pelo essencial: o que aqui é o armazenamento e quem é o guardião.

Banco de dados e SGBD

Um banco de dados (BD) é um conjunto organizado de dados. O instantâneo do «Kotomarket» guarda compradores, produtos, pedidos e eventos: nada está espalhado em arquivos soltos; tudo segue uma estrutura clara — e é por isso que ainda pode ser lido cento e sessenta anos depois.

Mas o armazenamento sozinho não responde a perguntas. É preciso um programa capaz de criar tabelas, registrar novos pedidos, ler os dados e garantir que as conexões não se rompam. Esse programa é um SGBD (sistema de gerenciamento de banco de dados). Exemplos: PostgreSQL, MySQL, ClickHouse. Nosso instantâneo é um banco PostgreSQL, e ele ainda fala o mesmo SQL de quando a loja estava ativa.

Você escreve uma consulta em SQL → envia para o SGBD → o SGBD busca os dados pedidos e devolve o resultado. O Excel é ótimo para uma planilha pessoal, mas não para uma loja em que milhares de usuários navegam pelos produtos, fazem pedidos e registram eventos no sistema ao mesmo tempo.

Database and DBMS

A database is an organized store. The Kotomarket snapshot holds buyers, products, orders, and events — not scattered across files, but in a clear structure. That’s exactly why it can still be read a hundred and sixty years later.

But the store itself doesn’t answer questions. You need a program that can create tables, record new orders, read data, and make sure the links never break. That’s a DBMS (database management system). Examples: PostgreSQL, MySQL, ClickHouse. Our snapshot is a PostgreSQL database, and it still speaks the same SQL it did when the shop was alive.

You write a query in SQL → send it to the DBMS → the DBMS fetches the data you asked for and returns the result. Excel is fine for a personal spreadsheet, but not for a shop where thousands of users browse products, place orders, and leave events in the system all at once.

O que um SGBD faz que «arquivos comuns» não conseguem

À primeira vista, a loja poderia funcionar sem um SGBD: bastaria gravar os pedidos em CSV ou Excel. Na escala de uma planilha pessoal, isso até funciona — até aparecerem os problemas para os quais o SGBD foi criado.

• Acesso concorrente. No «Kotomarket» em funcionamento, os compradores faziam pedidos ao mesmo tempo. Dois processos gravando no mesmo arquivo podem sobrescrever as alterações um do outro; um SGBD executa as alterações como transações e organiza sozinho as operações paralelas. O PostgreSQL faz isso pelo mecanismo MVCC: quem lê não bloqueia quem escreve, e vice-versa.
• Recuperação após falha. A energia oscilou no meio de uma gravação — o arquivo corrompeu, e não há como saber qual parte do pedido chegou a ser salva. O SGBD primeiro registra a alteração em um log (no PostgreSQL, o WAL — write-ahead log) e a reaplica depois da falha: o pedido é gravado por inteiro ou não é gravado.
• Controle de acesso. Um arquivo se abre por inteiro ou não se abre. Em um SGBD, as permissões são granulares — até o nível de uma única tabela:

-- O analista só pode ler os pedidos, sem direito de alterá-los
GRANT SELECT ON orders TO analyst;

• Integridade. Um SGBD não aceita um pedido com preço em formato de texto, nem uma referência a um comprador que não existe: os tipos das colunas e as restrições são verificados a cada gravação. Para um arquivo, tanto faz o que há dentro dele.
• Perguntas declarativas. «Mostre os pedidos acima de 5000» vira uma única linha de SQL. Com um arquivo, esse mesmo trabalho cairia sobre um programa que alguém teria que escrever — e acertar.