DBeaver: Concorrente Sério para o Squirrel Client

Boas ferramentas podem ajudar a organizar o trabalho e aumentar a produtividade. Quando falamos de bancos de dados, a necessidade de gerenciar conexões é crítica. A ferramenta DBeaver se une ao psql e ao Squirrel Client, posicionando-se como uma boa opção para gerenciamento de conexões, oferecendo recursos adicionais bastante úteis para criar conexões e scripts sql, relacionados ao postgresql e a outros SGBDs. Este post apresenta as características básicas deste software livre e de código aberto, sem a pretensão de esgotar as suas funcionalidades.

* Criação de conexão

O DBeaver oferece a possibilidade de baixar automaticamente o driver do postgresql na criação de uma conexão. O download funcionou, baixando o driver da versão 9.1 do banco.
A ferramenta oferece um driver manager que permite a migração de um conexão de um driver para outro mais recente, e a inclusão de novos drivers.

 Tipo de conexão

Dados da Conexão

Criação da Conexão

* Editor SQL

Apresenta recursos básicos úteis e atalhos relativamente simples de se utilizar.

Control + L - Abre editor.

Alt + ENTER - Executa parte selecionada do script.

Alt + X - Executa o script todo.

Control + Space - Oferece sugestões para completar os comandos SQL.

 Interface da Ferramenta

* Suporte a Projetos

O DBeaver apresenta a organização das conexões em projetos, permitindo maior produtividade por parte do usuário. Um projeto no dbeaver consiste em um conjunto de conexões e scripts SQL.

Os projetos criados na ferramenta podem ser exportados e importados, o que facilita o compartilhamento das conexões entre os membros de equipes de desenvolvimento.

* Controle do nível de isolamento das transações

Através do menu "Database/Transaction Mode" é possível visualizar e alterar o nível de isolamento utilizado nas consultas.

* DBeaver X Squirrel

Existe uma grande sobreposição de funcionalidades entre estas ferramentas. Utilizo mais o Squirrel client, por hábito, mas considero as opções como praticamente equivalentes.
Os recursos para gerenciamento de drivers de conexão e o suporte a projetos tendem a dar vantagem ao DBeaver em longo prazo, caso o scuirrel não se atualize.

O PostgreSQL Não Implementa o comando INSERT com a Cláusula SET

Você já utilizou a cláusula SET em um comando INSERT?  No postgresql, com certeza, não, pois a mesma não está implementada até a versão atual, a 9.3. Esta sintaxe pode ser descrita conforme aparece abaixo:

INSERT INTO nome_tabela SET coluna1 = expressão1, coluna2 = expressão2, .... ;

O fato é que esta sintaxe pouco acrescentaria em termos de valor. É pouco conhecida e pouco utilizada, embora eu acredite que esteja implementada em outros SGBDs. Sua funcionalidade seria idêntica à do comando INSERT já implementado, agregando possivelmente um pouco em termos de compatibilidade, embora não me recorde de ferramentas ou sistemas que utilizem esta sintaxe nas minhas andanças. 

Então porque estou comentando o fato do postgresql não implementar esta sintaxe?

Bom, justifico esta postagem por ter encontrado esta sintaxe em provas de concursos públicos, como nos exemplos abaixo. Não sei se a cláusula SET no INSERT faz parte do padrão ISO, mas não deixa de ser uma limitação, ainda que bem pequena.

Exemplos: 

Prova: FCC - 2012 - MPE-PE - Analista Ministerial - Informática

Disciplina: Banco de Dados | Assuntos: SQL;

Após a execução dos seguintes comandos SQL:

CREATE TABLE livros (id INT, nome TEXT);

INSERT INTO livros VALUES(1,'livro 1');

INSERT INTO livros (2,'livro 2');

INSERT INTO livros SET id=3,nome='livro 3';

SELECT id FROM livros;

O resultado da consulta para a coluna id será 

 

a) 3, apenas. b) 1, apenas. c) 1, 2 e 3. d) 2 e 3, apenas. e) 1 e 3, apenas.

Prova: FCC - 2012 - MPE-PE - Técnico Ministerial - Informática

Disciplina: Banco de Dados | Assuntos: SQL;

Analise os seguintes comandos em SQL:

CREATE TABLE nota (id INT PRIMARY KEY,data TEXT,valor REAL);

INSERT INTO nota SET id=1,data='01012012',valor=15.5;

INSERT INTO nota SET id=1,data='03022012',valor=11.5;

INSERT INTO nota SET id=2,data='01042012',valor=25.5;

INSERT INTO nota SET id=20,data='10062012',valor=12.5;

SELECT COUNT(*) FROM nota WHERE valor < 20;

O resultado para a consulta efetuada será: 

 

a) 12.5 b) 3 c) 11.5, 12.5 e 15.5 d) 2 e) 12.5 e 15.5

COALESCE: Trate decisões envolvendo campos nulos!

A função COALESCE permite que se selecione, entre dois ou mais parâmetros, o primeiro valor não nulo, retornando nulo caso todos os valores passados como parâmetro sejam nulos. É um recurso que pode ser utilizado para dar mais elegância ao tratamento de valores nulos e ao mesmo tempo reduzir o tamanho das consultas, tornando-as  mais fáceis de manter.

A sintaxe é bem simples, pois a função COALESCE recebe uma lista de valores como parâmetro, separados por vírgula.

Exemplo 1: Apenas um parâmetro fornecido

postgres=# SELECT COALESCE(1);
 coalesce
----------
        1
(1 registro)

Exemplo 2: Dois parâmetros fornecidos

postgres=# SELECT COALESCE(null,2);
 coalesce
----------
        2
(1 registro)

Exemplo 3: Três parâmetros fornecidos

postgres=# SELECT COALESCE(1,2,3);
 coalesce
----------
        1
(1 registro)

Exemplo 4: O primeiro parâmetro é nulo.

postgres=# SELECT COALESCE(null,2,3);
 coalesce
----------
        2
(1 registro)

Exemplo 5: Os dois primeiros parâmetros são nulos.

postgres=# SELECT COALESCE(null,null,3);
 coalesce
----------
        3
(1 registro)

Exemplo 6: Exemplo com cinco parâmetros e valor do tipo data.

postgres=# SELECT COALESCE(null, null, null, null, current_date);
  coalesce 
------------
 2014-05-02
(1 registro)

Exemplo 7: Exemplo utilizando campos de uma tabela como parâmetro.

postgres=# CREATE TEMP TABLE TBL_COA(campo1 INTEGER, campo2 INTEGER, campo3 INTEGER);
postgres=# INSERT INTO TBL_COA VALUES (null,1,2);
postgres=# INSERT INTO TBL_COA VALUES (null,null,2);
postgres=# INSERT INTO TBL_COA VALUES (null,null,null);

postgres=# SELECT COALESCE(campo1,campo2, campo3) FROM TBL_COA;
 coalesce
----------
        1
        2
        
(3 registros)

Exemplo 8: Implementação das condições do exemplo anterior utilizando a cláusula CASE. O plano de execução é o mesmo, mas o código fica bem mais complexo.
postgres=# SELECT
postgres-# CASE WHEN campo1 IS NOT NULL THEN campo1
postgres-# WHEN campo1 IS NULL AND campo2 IS NOT NULL THEN campo2
postgres-# WHEN campo1 IS NULL AND campo2 IS NULL AND campo3 IS NOT NULL THEN campo3
postgres-# ELSE null END AS simula_coalesce
postgres-# FROM TBL_COA;
 simula_coalesce
-----------------
               1
               2
               
(3 registros)

* Conclusões

- O uso de COALESCE pode tornar seu código mais enxuto e fácil de manter;

- Pode substituir a cláusula CASE no tratamento de valores NULOS, embora não haja ganho de desempenho.

explain.depesz: Encontre a Causa da Lentidão em suas Consultas!

O site http://explain.depesz.com/ disponibiliza uma ferramenta bastante útil, que formata, extrai e a apresenta de forma relativamente simples o conteúdo dos planos de execução do postgresql, permitindo uma análise mais fácil do mesmo. A promessa deste aplicativo é ajudar a encontrar a causa da lentidão nas consultas realizadas.

 Site da ferramenta

Para utilizar a ferramenta, basta acessar o site, colar na caixa de texto o resultado do comando EXPLAIN , e acionar a opção para submeter o plano. O sistema processará o plano de execução e apresentará o resultado de forma gráfica, indicando em tons de amarelo e vermelho os pontos mais críticos em termos de custo de processamento. Desta forma, fica mais fácil fazer o ajuste de performance de consultas.

 Plano analisado

Já escrevi alguma coisa sobre o comando explain aqui, aqui e aqui.
 
Pessoalmente gostei da ferramenta, embora ainda não me tenha sido realmente útil. Peço que testem e me digam o que acharam.

As Funções GREATEST e LEAST

As funções GREATEST e LEAST recuperam, respectivamente, o maior e o menor valor não nulo em uma lista de valores, caso existam. São bastante úteis e, embora não sejam parte do padrão sql, são compatíveis com funções similares fornecidas por outros SGBDs.

Saliento que para recuperar o maior e menor valores em colunas de uma tabela, devem ser utilizadas as funções de agregação MAX e MIN, respectivamente.

* Exemplos

1 - Exemplo básico

SELECT GREATEST(1,2);

2 - Exemplo básico com três parâmetros
 

SELECT GREATEST(1,2, 3, 4);

3 - Exemplo básico com datas

SELECT GREATEST(current_date,current_date + 10);

4 - Exemplo básico com cálculo simples

SELECT GREATEST(1*2,2*1);

5 - Exemplo com valor nulo ignora o nulo

SELECT GREATEST(10,11,null);

6 - Exemplo gerando valor nulo

SELECT GREATEST(null,null);

7- Exemplo com dados textuais

SELECT GREATEST('ANA','CLA','AVA');

8 - Exemplo com timestamps

SELECT GREATEST(timestamp '2014-04-02 14:30:00', timestamp '2014-04-02 14:30:01');





9 - Exemplos do uso de LEAST

SELECT LEAST(1,2, 3, 4);
SELECT LEAST(current_date,current_date + 10);
SELECT LEAST(1*2,2*1);
SELECT LEAST(10, 11, null);
SELECT LEAST('ANA','CLA','AVA');
SELECT LEAST(timestamp '2014-04-02 14:30:00', timestamp '2014-04-02 14:30:01');

10 - Exemplo de comparação entre campos de uma mesma tabela

CREATE TEMP TABLE NOTA (codigo REAL, nota1 REAL, nota2 REAL, nota3 REAL);
INSERT INTO NOTA VALUES (1,10,9,8);
INSERT INTO NOTA VALUES (2,9.5,8,8.5);
INSERT INTO NOTA VALUES (3,1,2,3);

SELECT codigo, GREATEST(nota1, nota2, nota3) AS MAIOR_NOTA, LEAST(nota1, nota2, nota3) AS MENOR_NOTA FROM NOTA;

Minha Foto Oficial da PGBR 2013!

PgBR 2013.

Eu estava lá.

Foi muito bom! REcomendo a PgBR 2014!

Simples e Útil: Visões Materializadas no PostgreSQL!

Visões materializadas são recursos introduzidos na versão 9.3 do postgresql. Enquanto visões tradicionais reexecutam uma consulta sempre que são referenciadas, visões materializadas dispensam este esforço pelos seus dados já estarem guardados desde a sua criação ou do último refresh (atualização de visão). Pode-se dizer que uma visão materializada é um objeto que contém o resultado de uma consulta, facilitando o acesso aos dados nela contidos.

A principal justificativa para se utilizar visões materializadas é a aceleração de consultas em grandes massas de dados. É importante observar que em sistemas com pouco espaço em disco e discos lentos, visões materializadas podem ter pouco efeito ou até impacto negativo por sobrecarregar ainda mais o hardware.

Para ter ainda mais desempenho,. é possível criar índices para visões materializadas.

No postgresql, a atualização de uma visão materializada é feita através do comando REFRESH MATERIALIZED VIEW, enquanto que a mudança do código da consulta da visão é feita através do comando ALTER MATERIALIZED VIEW. A exclusão de visões materializadas é feita com o comendo DROP MATERIALIZED VIEW.

Sintaxe básica:

CREATE MATERIALIZED VIEW nome_tabela
    [ (nome_coluna [, ...] ) ]
    [ WITH ( storage_parameter [= value] [, ... ] ) ]
    [ TABLESPACE nome_tablespace ]
    AS consulta
    [ WITH [ NO ] DATA ]
Exemplo 1: Criação de uma visão materializada simples

CREATE MATERIALIZED VIEW lista_tabelas AS
SELECT tablename FROM PG_TABLES ORDER BY tablename;
Exemplo 2: Refresh dos dados de uma visão materializada, pelo comando REFRESH MATERIALIZED VIEW.

REFRESH MATERIALIZED VIEW lista_tabelas;

Exemplo 3: Exclusão de uma visão materializada utilizando DROP MATERIALIZED VIEW. O comando drop view não exclui visões materializadas, e sim gera erro.

DROP MATERIALIZED VIEW lista_tabelas;

Exemplo 4: Criação de uma visão materializada sem dados. Neste caso, o comando REFRESH MATERIALIZED VIEW pode ser utilizado para popular a visão armazenada.

CREATE MATERIALIZED VIEW lista_tabelas_nodata AS
SELECT tablename FROM PG_TABLES ORDER BY tablename WITH NO DATA;
Exemplo 5: Criação de uma visão materializada simples, explicitando o tablespace utilizado

CREATE MATERIALIZED VIEW lista_indices TABLESPACE pg_default AS
SELECT schemaname, tablename, indexname, tablespace FROM PG_INDEXES;
Exemplo 6: Criação de uma visão materializada simples, utilizando o storage parameter fillfactor. São aceitos todos os tipos de storage parameters de uma tabela padrão, exceto OIDs, pois visões materializadas não apresentam identificador OID para cada registro.

CREATE MATERIALIZED VIEW lista_indices_fill50 WITH (fillfactor = 50) AS
SELECT schemaname, tablename, indexname, tablespace FROM PG_INDEXES;
Exemplo 7: Para saber quantas visões armazenadas você tem no seu servidor, utilize a visão PG_MATVIEWS.

SELECT * FROM PG_MATVIEWS;

Exemplo 8: Alteração de visão materializada. O comando ALTER MATERIALIZED VIEW apresenta uma sintaxe mais elaborada, merecendo mais espaço em um texto futuro.

ALTER MATERIALIZED VIEW lista_tabelas RENAME TO lista_relacoes;

* Conclusões

Visões materializadas são uma boa opção para aumento de performance sob certas condições.

Também facilitam a importação de visões materializadas disponíveis em outros SGBDs como ORACLE e SQL SERVER.

A implementação de visões materializadas é relativamente fácil e bastante útil.

Você já utilizou esta funcionalidade nos seus projetos? Qual foi a sua opinião?

Gere uma Dimensão Temporal para o seu Data Warehouse Utilizando o Postgresql!

A dimensão temporal em um data warehouse, e também em outros tipos de aplicação, pode assumir uma multitude de formatos. Encaminho a vocês o link de uma planilha desenvolvida por Tomáš Greif, que simplesmente gera praticamente tudo o que você poderia precisar em termos de dimensão temporal para uso em data warehouse. Espero que ela facilite o seu trabalho. Baixe e use à vontade!

Não precisa de macros! Para criar a tabela, inserir e atualizar dados, basta copiar as colunas H e seguintes para um editor de texto.

A única ressalva é que a planilha ainda não suporta feriados, mas essa funcionalidade você pode adicionar :)

O PostgreSQL e a Distinta Concorrência, segundo o Google Trends

O serviço Google Trends é muito útil para pesquisas envolvendo a comparação de variáveis e suas tendências ao longo do tempo. Fiz uma pequena experiência em relação ao postgresql e compartilho aqui os resultados.

A Primeira Pesquisa

A primeira pesquisa teve como bancos de dados investigados o Postgres, o Mysql, o Oracle e o Microsoft Sql Server.

O Postgresql teve uma procura menor que a dos demais SGBDs, e uma tendência de queda, mas todos os bancos de dados da pesquisa apresentaram tendência de queda nas buscas. Me pareceu que a procura pelo Postgeresql caiu menos que a dos demais SGBDs, mas acho que há um viés da minha parte :)

Me perguntei o porquê. Será que a área de banco de dados está em queda no momento?

A Segunda Pesquisa

Além dos elementos da primeira pesquisa, introduzi Cloud Computing na investigação. O resultado mostrou aumento consistente de interesse em cloud computing e de queda no interesse nos bancos de dados tradicionais.

Bom, em uma análise bem simplificada, pode-se pensar em uma tendência de crescimento de bancos de dados em nuvem em relação aos bancos de dados tradicionais. Mas em que grau? Só o futuro dirá!


Como Entender este Resultado?

Sinceramente não tenho elementos para apresentar algo conclusivo, mas creio que as tecnologias tradicionais de bancos de dados estão consolidadas, enquanto que cloud computing apresenta mais novidades e inovação. Daí o maior interesse e tendência positiva de crescimento.

O que você acha? Deixe uma nota nos comentários!

Beltrano: Base de Dados em Português para o PostgreSQL

Às vezes ideias simples melhoram a nossa vida. Compartilhar projetos simples pode ajudar muita gente. Este é o caso do Beltrano, base de dados em português desenvolvida para aplicações OLAP e OLTP e compatível com o postgresql, pelo analista Fábio de Salles, bastante conhecido na comunidade pentaho. O banco simula uma aplicação simples, com empregados, cursos e pedidos, ideal para treinamentos e o ensino de bancos de dados e tecnologias.

O autor criou projeto completo no sourceforge, com a modelagem na ferramenta power architect, e os bancos de dados produzidos disponibilizados para download. Adicionalmente, colocou um tutorial com o passo a passo para a criação das bases no postgresql.

Você é livre para conhecer, baixar, utilizar e melhorar o Beltrano!

Abaixo, modelagem da base OLTP: