Sql

Para testar uma consulta, muitas vezes precisamos de registros que ainda não existem. Para montar um relatório diário, precisamos mostrar inclusive as datas em que nenhum registro foi criado. O PostgreSQL oferece uma função útil nos dois casos: generate_series(). Ela produz um conjunto de linhas a partir de limites e de um passo. Esse conjunto pode alimentar um INSERT, compor um calendário ou participar de uma junção. No Lab 02 do PostgreSQL Reliability Lab , usei essa função na carga inicial de categorias, clientes e produtos. Neste episódio, vamos partir desse uso e construir um relatório que também mostra dias sem pedidos. ...

Subconsultas colocadas no FROM normalmente são independentes das tabelas que aparecem antes delas. Mas alguns problemas exigem que a subconsulta seja avaliada para cada linha externa. Um exemplo comum é buscar os três produtos mais vendidos de cada categoria. No PostgreSQL, LATERAL permite expressar essa dependência diretamente. O problema Considere as tabelas: CREATE TABLE categories ( category_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, name text NOT NULL UNIQUE ); CREATE TABLE products ( product_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, category_id bigint NOT NULL REFERENCES categories, name text NOT NULL, sales_count integer NOT NULL DEFAULT 0 ); Queremos listar cada categoria acompanhada dos três produtos com maior sales_count. ...

Agregações tradicionais reduzem várias linhas a um resultado por grupo. Isso é exatamente o que queremos ao calcular o total de vendas por vendedor. Mas e se precisarmos manter cada venda e, ao mesmo tempo, mostrar sua posição no ranking e o valor acumulado? Para esse tipo de problema, o SQL oferece funções de janela. O problema Considere uma tabela de vendas: CREATE TABLE vendas ( venda_id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, vendedor_id bigint NOT NULL, realizada_em timestamptz NOT NULL, valor numeric(12, 2) NOT NULL CHECK (valor > 0) ); Queremos exibir cada venda com: ...

Consultas SQL costumam crescer de maneira incremental. Primeiro precisamos filtrar os dados. Depois agregar por cliente, calcular uma média, comparar cada resultado com essa média e ordenar somente os casos mais relevantes. Quando todas essas etapas ficam aninhadas em uma única expressão, a consulta pode continuar correta, mas se torna difícil de ler e modificar. Uma Common Table Expression, ou CTE, permite dividir esse raciocínio em resultados nomeados. O problema Considere uma tabela com execuções de pipelines: ...

Integrações, cargas de dados e consumidores de eventos frequentemente precisam executar uma operação simples de descrever: Se o registro ainda não existe, insira. Se já existe, atualize. Esse comportamento é conhecido como upsert, combinação de update e insert. No PostgreSQL, ele pode ser implementado com INSERT ... ON CONFLICT. O problema Considere uma tabela que registra o estado mais recente de cada pipeline em uma data de referência: CREATE TABLE pipeline_status ( pipeline text NOT NULL, reference_date date NOT NULL, status text NOT NULL, attempts integer NOT NULL DEFAULT 1, updated_at timestamptz NOT NULL DEFAULT now(), CONSTRAINT pipeline_status_uk UNIQUE (pipeline, reference_date) ); Uma mesma execução pode ser informada novamente por retry, reprocessamento ou entrega duplicada de mensagem. ...

Aprender SQL costuma começar com SELECT, WHERE, JOIN, GROUP BY e ORDER BY. Esses fundamentos resolvem muitos problemas, mas o trabalho cotidiano com bancos de dados logo exige mais. Precisamos obter o registro mais recente de cada grupo, calcular acumulados, carregar dados sem criar duplicidades, investigar consultas lentas e coordenar operações concorrentes. Nesse ponto, conhecer apenas a sintaxe básica deixa de ser suficiente. Este artigo reúne dez recursos que considero especialmente úteis para quem trabalha com PostgreSQL, Engenharia de Dados, DBRE ou desenvolvimento de sistemas. A lista não pretende esgotar o SQL. Ela funciona como um mapa do que estudar depois dos fundamentos. ...

Em plataformas de dados, é comum armazenarmos o histórico de execuções de cada pipeline. Uma mesma rotina pode ter sido executada dezenas ou centenas de vezes, mas algumas consultas precisam mostrar apenas seu estado mais recente. No PostgreSQL, podemos resolver esse problema de forma concisa com DISTINCT ON. O problema Considere uma tabela que registra as execuções de pipelines: CREATE TABLE execucoes_pipeline ( id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, pipeline text NOT NULL, status text NOT NULL, iniciado_em timestamptz NOT NULL, finalizado_em timestamptz ); Cada linha representa uma execução: ...

Em relatórios SQL, é comum precisarmos calcular diferentes totais a partir do mesmo conjunto de dados. Imagine uma tabela de pedidos com a seguinte estrutura: CREATE TABLE pedidos ( id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, cliente_id bigint NOT NULL, status text NOT NULL, valor numeric(12, 2) NOT NULL, criado_em timestamp NOT NULL DEFAULT current_timestamp ); Queremos apresentar, em uma única consulta: quantidade total de pedidos; pedidos pagos; pedidos pendentes; pedidos cancelados; valor total dos pedidos pagos. A solução tradicional com CASE Uma forma comum de resolver o problema é colocar expressões CASE dentro das funções de agregação: ...

Ao inserir um registro no PostgreSQL, é comum precisar do identificador gerado pelo banco para continuar o processamento. Uma solução possível é executar o INSERT e, em seguida, fazer outra consulta. O PostgreSQL oferece uma alternativa mais direta: a cláusula RETURNING. O problema Considere uma tabela que armazena tarefas de processamento: CREATE TABLE jobs ( id bigint GENERATED ALWAYS AS IDENTITY PRIMARY KEY, file_path text NOT NULL, status text NOT NULL DEFAULT 'pending', created_at timestamptz NOT NULL DEFAULT now() ); Depois de criar um job, a aplicação precisa conhecer o id, o estado inicial e a data atribuída pelo banco. ...

O que é PostgreSQL O PostgreSQL é um sistema gerenciador de banco de dados objeto-relacional e open source. Na prática, isso significa combinar aderência forte ao padrão SQL com recursos clássicos de bancos relacionais, como transações, integridade e controle de concorrência, sem abrir mão de extensibilidade para criar tipos, funções, operadores e extensões. Esse equilíbrio explica por que ele é visto como um banco de dados generalista: funciona muito bem em sistemas transacionais e também atende cenários analíticos e geoespaciais. ...