Sql-Da-Semana

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. ...