Bases de Dados e SQL

Até agora, todos os dados que criaste — arrays, objetos, variáveis — existiam só enquanto o programa estava a correr. Assim que o node ficheiro.js terminava, tudo desaparecia. Uma base de dados resolve isto: guarda dados num ficheiro (ou num serviço externo), de forma organizada, para que continuem a existir depois do programa terminar e possam ser partilhados por vários programas ao mesmo tempo.

Bases de dados relacionais

Existem vários tipos de base de dados; nesta plataforma vais focar-te nas relacionais, que organizam dados em tabelas — parecidas com folhas de cálculo, mas com regras mais rígidas e formas poderosas de as relacionar entre si. É o tipo mais usado no mundo, e a linguagem para as interrogar chama-se SQL (Structured Query Language).

Porquê SQLite nesta plataforma

Vamos usar o SQLite, uma base de dados que vive num único ficheiro (.db) no teu computador — sem precisares de instalar nem configurar um servidor de base de dados separado. É exatamente a mesma linguagem SQL que vais usar depois com bases de dados maiores (PostgreSQL, MySQL) em projetos reais; muda o motor por trás, não a forma como escreves as consultas.

Uma pequena parte do vocabulário, antes de avançar

• Tabela — uma coleção de registos do mesmo tipo (ex: uma tabela utilizadores).
• Linha (row) — um registo individual dentro da tabela (ex: um utilizador específico).
• Coluna — um campo que toda a linha da tabela tem (ex: nome, email).
• Consulta (query) — uma instrução escrita em SQL que pedes à base de dados para executar.

Vais ver estes quatro termos constantemente a partir daqui.

Antes de guardares qualquer dado, tens de definir a estrutura da tabela — que colunas existem, e que tipo de dado cada uma aceita.

CREATE TABLE utilizadores (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  nome TEXT NOT NULL,
  email TEXT NOT NULL,
  idade INTEGER
);

Chave primária (PRIMARY KEY)

Toda a tabela deve ter uma coluna que identifica de forma única cada linha — a chave primária. Aqui é a coluna id, marcada como INTEGER PRIMARY KEY AUTOINCREMENT: um número inteiro que a própria base de dados gera automaticamente e aumenta a cada nova linha, garantindo que nunca há dois registos com o mesmo id.

Restrições comuns

• NOT NULL — esta coluna é obrigatória; a base de dados recusa guardar uma linha sem valor aqui.
• UNIQUE — não pode haver dois registos com o mesmo valor nesta coluna (ex: dois utilizadores com o mesmo email).
• DEFAULT valor — se não fornecer um valor, usa este por defeito.

Chave estrangeira (FOREIGN KEY): relacionar tabelas

O nome "base de dados relacional" vem daqui: uma tabela pode referenciar uma linha de outra tabela através de uma chave estrangeira.

CREATE TABLE tarefas (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  titulo TEXT NOT NULL,
  utilizador_id INTEGER,
  FOREIGN KEY (utilizador_id) REFERENCES utilizadores (id)
);

A coluna utilizador_id em tarefas guarda o id de um registo em utilizadores — é assim que dizes "esta tarefa pertence a este utilizador", sem teres de copiar todos os dados do utilizador para dentro de cada tarefa. Este tipo de relação (uma tarefa pertence a um utilizador) chama-se um-para-muitos, e é o padrão mais comum em aplicações reais.

SELECT é o comando para ler dados de uma tabela:

SELECT nome, email FROM utilizadores;

Isto devolve as colunas nome e email de todas as linhas da tabela utilizadores. Para pedir todas as colunas de uma vez, usa SELECT * FROM utilizadores; — o asterisco significa "todas".

Filtrar com WHERE

WHERE restringe quais as linhas devolvidas, com uma condição — a mesma ideia dos if que já conheces, mas aplicada a dados guardados:

SELECT * FROM utilizadores WHERE idade >= 18;

SELECT * FROM utilizadores WHERE nome = 'Ana';

SELECT * FROM tarefas WHERE utilizador_id = 3 AND concluida = 0;

Repara que AND e OR funcionam em SQL tal como && e || funcionam em JavaScript — combinam várias condições da mesma forma lógica.

Ordenar com ORDER BY

ORDER BY decide a ordem das linhas devolvidas:

SELECT * FROM utilizadores ORDER BY idade DESC;

DESC ordena do maior para o menor (descendente); ASC (o padrão, podes omitir) ordena do menor para o maior.

Limitar resultados com LIMIT

Quando só precisas das primeiras N linhas (ex: as 5 tarefas mais recentes):

SELECT * FROM tarefas ORDER BY id DESC LIMIT 5;

Combinar WHERE, ORDER BY e LIMIT na mesma consulta é extremamente comum — é assim que a maioria dos ecrãs de listagem de uma aplicação real (produtos, mensagens, publicações) pede dados à base de dados.

INSERT: adicionar uma nova linha

INSERT INTO utilizadores (nome, email, idade)
VALUES ('Marta', 'marta@email.com', 25);

Não precisas de indicar a coluna id — como definiste AUTOINCREMENT no tema 2, a base de dados atribui-o automaticamente.

UPDATE: alterar linhas existentes

UPDATE utilizadores SET idade = 26 WHERE nome = 'Marta';

O WHERE aqui não é opcional na prática. Um UPDATE sem WHERE altera todas as linhas da tabela — é um dos erros mais caros que um programador pode cometer, e infelizmente já aconteceu a gente experiente em bases de dados de produção. O hábito certo: escreve sempre primeiro o SELECT equivalente com o mesmo WHERE, confirma que devolve exatamente as linhas que queres alterar, e só depois troca SELECT * por UPDATE ... SET ....

DELETE: remover linhas

DELETE FROM utilizadores WHERE id = 7;

A mesma regra do UPDATE aplica-se, ainda com mais força: DELETE FROM utilizadores; sem WHERE apaga toda a tabela, sem aviso e sem confirmação. Testa sempre o WHERE com um SELECT primeiro.

Resumo dos quatro verbos (CRUD)

Estes quatro comandos formam o que se chama CRUD — Create, Read, Update, Delete — as quatro operações básicas que qualquer aplicação com dados persistentes precisa de suportar. Repara na correspondência direta com os métodos HTTP que viste na Fase 5: POST costuma disparar um INSERT, GET um SELECT, PUT/PATCH um UPDATE, DELETE um... DELETE.

Para uma aplicação web usar a tua base de dados, precisas de um servidor que receba pedidos HTTP (Fase 5) e responda executando consultas SQL. Em Node.js, a combinação mais comum para começar é o Express (para o servidor) com better-sqlite3 (para falar com o ficheiro .db).

const express = require('express');
const Database = require('better-sqlite3');

const app = express();
app.use(express.json());

const db = new Database('dados.db');

db.exec(`
  CREATE TABLE IF NOT EXISTS tarefas (
    id INTEGER PRIMARY KEY AUTOINCREMENT,
    titulo TEXT NOT NULL,
    concluida INTEGER DEFAULT 0
  )
`);

app.get('/tarefas', (req, res) => {
  const tarefas = db.prepare('SELECT * FROM tarefas').all();
  res.json(tarefas);
});

app.post('/tarefas', (req, res) => {
  const { titulo } = req.body;
  const resultado = db.prepare('INSERT INTO tarefas (titulo) VALUES (?)').run(titulo);
  res.status(201).json({ id: resultado.lastInsertRowid, titulo });
});

app.listen(3000, () => console.log('Servidor a correr na porta 3000'));

O ponto de interrogação: consultas parametrizadas

Reparaste no ? dentro de VALUES (?)? Isto chama-se consulta parametrizada — em vez de "colares" o valor diretamente na string SQL, passas-lhe o valor separadamente através de .run(valor). Isto não é opcional por estilo: colar valores vindos do utilizador diretamente numa string SQL abre a porta a um ataque chamado SQL injection, onde alguém malicioso escreve, no lugar de um nome, código SQL que apaga ou rouba dados. Consultas parametrizadas eliminam esse risco por completo — usa-as sempre que um valor vier de fora do teu código (de um formulário, de um pedido HTTP).

O ciclo completo

1. 1O navegador (ou uma ferramenta como o Postman) envia um pedido HTTP.
2. 2O Express recebe o pedido na rota correta (app.get, app.post, etc.).
3. 3O código da rota executa uma consulta SQL na base de dados.
4. 4O resultado é devolvido como resposta HTTP, normalmente em JSON.

Isto fecha o círculo entre tudo o que aprendeste desde a Fase 5: HTTP, rotas, e agora persistência real.