As pesquisas na internet dizem muito sobre a aceitação de produtos, serviços, candidatos a cargos eletivos e sobre o uso de programas e sistemas. Com o PostgreSQL não é diferente. Fiz uma breve pesquisa sobre o ano de 2009 no google insights e os resultados compartilho neste post. O levantamento do ano passado está aqui.
As imagens capturadas e os dados foram todos coletados dia 18/12/2009.
- O ano de 2009 foi relativamente estável. Houve uma queda nas buscas com a festas de fim de ano e um aumento nas pesquisas durante o lançamento da nova versão 8.4, em meados de abril. A figura 1 mostra a evolução destas buscas no ano.
Considerando os últimos 4 anos, houve uma diminuição nas buscas. No entanto isto não significa necessariamente perda de espaço, podendo indicar também uma maior disseminação do conhecimento sobre o banco, que reduz a necessidade de pesquisas na rede.
- No mundo, Japão e Rússia crescem no ranking relativo de buscas e recuperam as primeiras posições perdidas em 2008 para Cuba e China.
- No mundo ganha destaque a busca "PostgreSQL MySQL", indício de que o PostgreSQL não é considerado uma alternativa tão natural ao Oracle ou ao Sql Server, mas uma boa opção em relação ao MySQL (Esta é apenas uma suposição que carece de mais comprovação!).
- No Brasil destaco as buscas "PostgreSQL Windows" e "PostgreSQL Linux". A pontuação destas buscas mostra que a compatibilidae com vários sistemas operacionais é um importante fator para os projetos de software nacionais.
- O Brasil continua em uma posição intermediária. Na América do Sul o destaque fica para a Bolívia, que ocupa a quarta posição entre os 10 maiores índices de busca pelo PostgreSQL no Google.
- Dentre os estados brasileiros, Distrito Federal e Ceará ocupam as duas primeiras posições. Santa Catarina, Paraná e Rio Grande do Sul estão nas três posições subsequentes, o que mostra a força do PostgreSQL na Região Sul.
Não recomendo que estes dados sejam utilizados para a tomada de decisões. São informações retrospectivas sujeitas a erros estatísticos! 2009 está consumado. Agora é trabalhar pelo 2010!
No ar desde 2007! Blog com informações e notícias sobre o banco de dados PostgreSQL, aquele que todos adoramos usar. Trata-se de uma ferramenta livre e de código aberto, mantida por uma comunidade ativa de usuários da qual você é convidado fazer parte. Textos, ideias e outras contribuições podem ser enviadas para Cláudio Bezerra Leopoldino: claudiob_br@yahoo.com.br
sexta-feira, 18 de dezembro de 2009
quinta-feira, 17 de dezembro de 2009
GreenSQL: O Rinoceronte Amigo do Elefante!
Segurança nunca é demais e cautela e caldo de galinha não fazem mal a ninguém! No caso do PostgreSQL não é diferente, e qualquer atualização de segurança é sempre recomendada.
O GreenSQL é um firewall de código aberto que visa proteger bases de dados de ataques tipo "SQL Injection", verificando os comandos submetidos ao banco, restringindo comandos de administrador para criação e destruição de tabelas e outros objetos e impedindo a submissão de códigos maliciosos. Seu símbolo é o do Rinoceronte.
A versão mais recente agregou o suporte ao PostgreSQL ao do MySQL já existente. Espera-se que o Rinoceronte possa agir como guarda costas do elefante a partir deste lançamento! Abaixo, uma imagem da arquitetura do GreenSQL.
A licença é GPL. Teste e me diga o que achou!
O GreenSQL é um firewall de código aberto que visa proteger bases de dados de ataques tipo "SQL Injection", verificando os comandos submetidos ao banco, restringindo comandos de administrador para criação e destruição de tabelas e outros objetos e impedindo a submissão de códigos maliciosos. Seu símbolo é o do Rinoceronte.
A versão mais recente agregou o suporte ao PostgreSQL ao do MySQL já existente. Espera-se que o Rinoceronte possa agir como guarda costas do elefante a partir deste lançamento! Abaixo, uma imagem da arquitetura do GreenSQL.
A licença é GPL. Teste e me diga o que achou!
quinta-feira, 10 de dezembro de 2009
Enquete aponta que PostgreSQL Crescerá com a Compra do MySQL
A compra recente da Sun pela Oracle, incluindo o banco MySQL começa a trazer mudanças no mercado. Segundo enquete realizada pelo "The 451 Group", há uma tendência de redução do market share do MySQL em detrimento do PostgreSQL e do novo banco de dados MariaDB, que seria um fork livre do MySQL com um processamento de consultas novo e bastante promissor.
Este autor acha que há espaço para todos, e acredita no crescimento do PostgreSQL independentemente do apresentado pelas demais alternativas. Aproveita para lembrar que enquetes revelam apenas intenções, e que o mercado pode tomar outra direção.
O que você acha? O que tem acontecido na sua empresa?
O artigo original pode ser obtido aqui.
Este autor acha que há espaço para todos, e acredita no crescimento do PostgreSQL independentemente do apresentado pelas demais alternativas. Aproveita para lembrar que enquetes revelam apenas intenções, e que o mercado pode tomar outra direção.
O que você acha? O que tem acontecido na sua empresa?
O artigo original pode ser obtido aqui.
sexta-feira, 27 de novembro de 2009
O Comando Table
O comando TABLE é muito pouco conhecido entre os usuário do Postgres, no entanto isto não chega a ser um problema. É um comando que funciona mais como uma curiosidade do que como uma funcionalidade real. Sua função principal é economizar digitação de consultas relativas a todos os dados de uma tabela.
Consultas com a sintaxe abaixo, por exemplo:
SELECT * FROMtabela;
Poderiam ser simplificadas para:
TABLE tabela;
O ganho é apenas de tempo de digitação ou de simplificação. O plano de execução é o mesmo.
O comando TABLE pode ser utilizado no lugar de "SELECT * FROM" de diversas maneiras diferentes:
Exemplo 1:
TABLE ADDRESS; --Recupera todas as colunas e linhas da tabela ADDRESS
Exemplo 2:
TABLE ADDRESS ORDER BY postal_code; --Classifica e recupera todas as colunas e linhas da tabela ADDRESS
Exemplo 3:
TABLE ADDRESS ORDER BY postal_code DESC; --Classifica de modo decrescente e recupera todas as colunas e linhas da tabela ADDRESS
Exemplo 4:
SELECT * FROM ADDRESS
UNION ALL
TABLE ADDRESS; --Uso de TABLE com UNION
Consultas com a sintaxe abaixo, por exemplo:
SELECT * FROM
Poderiam ser simplificadas para:
TABLE
O ganho é apenas de tempo de digitação ou de simplificação. O plano de execução é o mesmo.
O comando TABLE pode ser utilizado no lugar de "SELECT * FROM" de diversas maneiras diferentes:
Exemplo 1:
TABLE ADDRESS; --Recupera todas as colunas e linhas da tabela ADDRESS
Exemplo 2:
TABLE ADDRESS ORDER BY postal_code; --Classifica e recupera todas as colunas e linhas da tabela ADDRESS
Exemplo 3:
TABLE ADDRESS ORDER BY postal_code DESC; --Classifica de modo decrescente e recupera todas as colunas e linhas da tabela ADDRESS
Exemplo 4:
SELECT * FROM ADDRESS
UNION ALL
TABLE ADDRESS; --Uso de TABLE com UNION
quinta-feira, 26 de novembro de 2009
Tutorial de PostgreSQL e Hibernate
Bom tutorial introdutório de PostgreSQL com Hibernate aqui.
O autor autoriza o uso mas não a redistribuição!
O autor autoriza o uso mas não a redistribuição!
terça-feira, 3 de novembro de 2009
PostgreSQL 8.5 - Versão Alfa
Como desenvolver uma ferramenta altamente poderosa? Certamente um dos passos é a atualização e renovação constante. No caso do PostgreSQL, antes que uma versão seja lançada, existe um planejamento das futuras implementações. Desta forma, sempre existe um horizonte de crescimento.
A versão 8.4 está sendo atalizada com correções e ajustes nas fuincionalidades, mas em paralelo, a nova versão 8.5 está em desenvolvimento, estando em sua versão alfa. O site para download se encontra aqui. A versão alpa 2 está disponível para download e são disponibilizadas informações sobre as novas funcionalidades para a versão 8.5!
A versão 8.4 está sendo atalizada com correções e ajustes nas fuincionalidades, mas em paralelo, a nova versão 8.5 está em desenvolvimento, estando em sua versão alfa. O site para download se encontra aqui. A versão alpa 2 está disponível para download e são disponibilizadas informações sobre as novas funcionalidades para a versão 8.5!
quinta-feira, 24 de setembro de 2009
Monitoração de Comandos com PG_STAT_STATEMENTS
Na versão 8.4, foram acrescentados novos recursos de monitoramento de banco que podem ser bastante úteis para se identificar que consultas têm consumido mais tempo, retornam mais dados e quais são executadas com maior freqüência. A pg_stat_statements é uma biblioteca que monitora e coleta estas informações para o usuário.
Para monitorar o que acontece no sgbd, é necessário manter em memória uma rotina que realize essa atividade. Para colocar esta rotina em execução, deve ser alterado o arquivo de configuração, mais precisamente a variável “shared_preload_libraries”, e reiniciado o servidor. Acrescente no arquivo de configuração postgresql.conf a linha abaixo e reinicie o serviço do banco:
shared_preload_libraries = '$libdir/pg_stat_statements'
Para visualizar se a biblioteca realmente foi colocada na memória pode ser usado o comando show:
Show shared_preload_libraries
Execute algumas consultas para que o sgbd armazene valores monitorados. Serão guardados os códigos dos comandos, o número de vezes em que os mesmos foram executados e os tempos de execução.
O próximo passo é executar o script do arquivo “contrib/pg_stat_statements/pg_stat_statements.sql” que se encontra na pasta de contribs para criar uma visão que mostrará os dados monitorados chamada pg_stat_statements. Abaixo, coloco a consulta padrão aos dados de monitoramento e alguns exemplos adicionais de consultas por número de chamadas ao comando, pelo tempo total e pelo número de linhas retornado.
1 - Consulta padrão
select * from pg_stat_statements;
2 - Consultas ordenadas pelo número de chamadas
select * from pg_stat_statements order by calls desc;
3 - Consultas ordenadas pelo tempo total utilizado
select * from pg_stat_statements order by total_time desc;
4 - Consultas ordenadas pelo número de linhas retornado
select * from pg_stat_statements order by rows desc;
Caso a quantidade de dados retornados seja muito grande, utilize a função pg_stat_statements_reset para limpar os dados coletados:
1 – Limpando dados coletados
select pg_stat_statements_reset();
Para monitorar o que acontece no sgbd, é necessário manter em memória uma rotina que realize essa atividade. Para colocar esta rotina em execução, deve ser alterado o arquivo de configuração, mais precisamente a variável “shared_preload_libraries”, e reiniciado o servidor. Acrescente no arquivo de configuração postgresql.conf a linha abaixo e reinicie o serviço do banco:
shared_preload_libraries = '$libdir/pg_stat_statements'
Para visualizar se a biblioteca realmente foi colocada na memória pode ser usado o comando show:
Show shared_preload_libraries
Execute algumas consultas para que o sgbd armazene valores monitorados. Serão guardados os códigos dos comandos, o número de vezes em que os mesmos foram executados e os tempos de execução.
O próximo passo é executar o script do arquivo “contrib/pg_stat_statements/pg_stat_statements.sql” que se encontra na pasta de contribs para criar uma visão que mostrará os dados monitorados chamada pg_stat_statements. Abaixo, coloco a consulta padrão aos dados de monitoramento e alguns exemplos adicionais de consultas por número de chamadas ao comando, pelo tempo total e pelo número de linhas retornado.
1 - Consulta padrão
select * from pg_stat_statements;
2 - Consultas ordenadas pelo número de chamadas
select * from pg_stat_statements order by calls desc;
3 - Consultas ordenadas pelo tempo total utilizado
select * from pg_stat_statements order by total_time desc;
4 - Consultas ordenadas pelo número de linhas retornado
select * from pg_stat_statements order by rows desc;
Caso a quantidade de dados retornados seja muito grande, utilize a função pg_stat_statements_reset para limpar os dados coletados:
1 – Limpando dados coletados
select pg_stat_statements_reset();
segunda-feira, 24 de agosto de 2009
Participe de Concurso "O Elefante está entre nós" e Concorra a 50 Prêmios!!!
A imaginação é mais importante que o conhecimento. E uma iniciativa brasileira promete estimular e recompensar a criativivade da comunidade PostgreSQL, distribuindo 50 prêmios. Apenas a participação de todos pode fazer desta boa idéia um grande sucesso! Se inscreva na PGCON e mostre seu conhecimento!
O concurso apresenta várias categorias:
O pai da idéia é o Telles, do blog Savepoint: http://www.midstorm.org/~telles/2009/08/22/concurso-o-elefante-esta-entre-nos/
As regras de cada categoria estão disponíveis aqui!
Se esta iniciativa for bem sucedida, certamente será reproduzida mundo afora. Depende da participação de todos! Este blogueiro parabeniza a iniciativa e tentará participar de pelo menos duas categorias, dentro do espírito olímpico: o "importante é competir".
O concurso apresenta várias categorias:
- Consulta ou script;
- Artigo;
- Artigo traduzido;
- História em quadrinhos; (!!!)
- Estudo de caso;
O pai da idéia é o Telles, do blog Savepoint: http://www.midstorm.org/~telles/2009/08/22/concurso-o-elefante-esta-entre-nos/
As regras de cada categoria estão disponíveis aqui!
Se esta iniciativa for bem sucedida, certamente será reproduzida mundo afora. Depende da participação de todos! Este blogueiro parabeniza a iniciativa e tentará participar de pelo menos duas categorias, dentro do espírito olímpico: o "importante é competir".
quarta-feira, 29 de julho de 2009
151 posts!
Em abril de 2007 este blog surgiu e hoje, pouco mais de 2 anos depois, atingiu a marca de 150 posts.
É muito pouco em comparação com blogs de entretenimento e variedades, mas é muito em relação a blogs de tecnologia, especialmente se a área é banco de dados, e especificamente o banco de dados PostgreSQL. A longevidade do blog também merece destaque, pois muitos outros bons sites deixaram de existir no período, congelaram no tempo, ou mudaram de rumo, abordando outros assuntos.
A dinâmica de inovação constante e os movimentos da comunidade ajudaram a atingir esta conquista.
Deus ajudou dando saúde e disposição! E você, leitor, ajudou de muitas formas, obrigado!
É muito pouco em comparação com blogs de entretenimento e variedades, mas é muito em relação a blogs de tecnologia, especialmente se a área é banco de dados, e especificamente o banco de dados PostgreSQL. A longevidade do blog também merece destaque, pois muitos outros bons sites deixaram de existir no período, congelaram no tempo, ou mudaram de rumo, abordando outros assuntos.
A dinâmica de inovação constante e os movimentos da comunidade ajudaram a atingir esta conquista.
Deus ajudou dando saúde e disposição! E você, leitor, ajudou de muitas formas, obrigado!
Psql 8.4: Novas Funcionalidades!
O psql em sua nova versão apresenta uma série de pequenas novidades, inclusive a promessa de compatibilidade com versões anteriores do Postgres, permitindo que de um console se acesse bancos de servidores mais antigos. A lista de alterações completa pode ser vista aqui. Abaixo, comento algumas das mudanças que reputo como mais significativas:
Listando o Tamanho de Objetos
Pequenas funcionalidades podem ser ainda mais interessantes para o usuário do utilitário que os avanços mais complexos. A facilidade de se obter informações detalhadas, particularmente sobre espaço ocupado por objetos em disco certamente é uma delas.
O uso da sintaxe \dt lista as tabelas criadas no banco. Na versão 8.4, pode ser utilizada a sintaxe \dt+, que retorna o espaço em disco ocupado pela tabela.
Este recurso também pode ser utilizado para índices. Digite \di para informações dos índices, e \di+ para um maior detalhamento com espaço em disco ocupado e descrição.
Para bancos de dados, a sintaxe é a mesma. Digite \l para informações dos bancos de dados, e \l+ para um maior detalhamento com espaço em disco ocupado e descrição.
Abrindo Editor para Funções
Editar funções dentro do psql não é uma tarefa muito agradável. Paras códigos mais extensos chega a ser penosa. Para minorar o problema, a opção \ef abre um editor externo para edição do código.
A sintaxe é: \ef
No windows, abre o notepad. Edite o texto, salve e feche o editor. No psql, digite ';' e tecle ENTER. O sistema vai registrar as alterações na função.
Listando o Tamanho de Objetos
Pequenas funcionalidades podem ser ainda mais interessantes para o usuário do utilitário que os avanços mais complexos. A facilidade de se obter informações detalhadas, particularmente sobre espaço ocupado por objetos em disco certamente é uma delas.
O uso da sintaxe \dt lista as tabelas criadas no banco. Na versão 8.4, pode ser utilizada a sintaxe \dt+, que retorna o espaço em disco ocupado pela tabela.
Este recurso também pode ser utilizado para índices. Digite \di para informações dos índices, e \di+ para um maior detalhamento com espaço em disco ocupado e descrição.
Para bancos de dados, a sintaxe é a mesma. Digite \l para informações dos bancos de dados, e \l+ para um maior detalhamento com espaço em disco ocupado e descrição.
Abrindo Editor para Funções
Editar funções dentro do psql não é uma tarefa muito agradável. Paras códigos mais extensos chega a ser penosa. Para minorar o problema, a opção \ef abre um editor externo para edição do código.
A sintaxe é: \ef
No windows, abre o notepad. Edite o texto, salve e feche o editor. No psql, digite ';' e tecle ENTER. O sistema vai registrar as alterações na função.
PostgreSQL 8.4 - Silêncio no Planeta Postgresql!
Achei interessante o silêncio sobre a nova versão do PostgreSQL na comunidade. O site do Planeta PostgreSQL BR não teve nenhum post novo desde 08/07/2009.
21 dias sem posts? Ou todos estão muito ocupados ou faltam novidades significativas. Espero que seja a primeira opção, pois foi o que aconteceu comigo!
21 dias sem posts? Ou todos estão muito ocupados ou faltam novidades significativas. Espero que seja a primeira opção, pois foi o que aconteceu comigo!
quarta-feira, 8 de julho de 2009
PostgreSQL 8.4: Falta um bom instalador para Windows!
Dentre as mais de 290 mudanças da versão 8.3.x para a 8.4.0, uma importante lacuna que surgiu foi a do instalador para windows. O projeto pgInstaller, mantido por Dave Page e Magnus Hagander gerou instaladores intuitivos e poderosos, com recursos de configuração mais avançados que facilitavam a adição de contribs e a atualização de versão do SGBD em ambiente Windows. No entanto, o projeto só continuará a ser mantido nas versões 8.2.x e 8.3.x.
Para Linux, além do one-click installer e de live cds, customizações de instaladores para Fedora, SUZE, Ubuntu e Debian estão disponíveis para o PostgreSQL 8.4.
Mais informações aqui!
Espera-se que sujam mais opções de instaladores além do limitado "One-Click Installer" da página oficial do PostgreSQL. Quem se habilita a fazer um?
Creio que o impacto para a difusão do PostgreSQL 8.4 pode ser significativo na plataforma Windows. Não podemos subestimar o impacto da facilidade de instalação para a adoção e atualização de qualquer ferramenta. O que vocês acham?
Complemento 13/08/2009:
- Depois de instalar em algumas máquinas, posso afirmar que o one-click installer é bastante funcional e estável. No entanto, continuo a me sentir incomodado por ter menos uma opção de instalação. E o desafio continua a quem se dispor a fazer um instalador alternativo!!!
Para Linux, além do one-click installer e de live cds, customizações de instaladores para Fedora, SUZE, Ubuntu e Debian estão disponíveis para o PostgreSQL 8.4.
Mais informações aqui!
Espera-se que sujam mais opções de instaladores além do limitado "One-Click Installer" da página oficial do PostgreSQL. Quem se habilita a fazer um?
Creio que o impacto para a difusão do PostgreSQL 8.4 pode ser significativo na plataforma Windows. Não podemos subestimar o impacto da facilidade de instalação para a adoção e atualização de qualquer ferramenta. O que vocês acham?
Complemento 13/08/2009:
- Depois de instalar em algumas máquinas, posso afirmar que o one-click installer é bastante funcional e estável. No entanto, continuo a me sentir incomodado por ter menos uma opção de instalação. E o desafio continua a quem se dispor a fazer um instalador alternativo!!!
quarta-feira, 1 de julho de 2009
PostgreSQL 8.4 Enfim Liberado!
O download do PostgreSQL 8.4 (8.4.0) foi enfim liberado!
A nova versão promete mais velocidade e facilidade de uso, melhorias no monitoramento e administração. É instalar e testar para ver! Em breve detalharei neste espaço as principais novidades deste aguardado release!
Abaixo, os links mais úteis:
* Download
http://www.postgresql.org/download/
* Notas de Lançamento
http://www.postgresql.org/docs/8.4/static/release-8-4.html
* Funções implementadas na versão
http://www.postgresql.org/about/press/features84.html
* Press Release
http://www.postgresql.org/about/press/presskit84.html
A nova versão promete mais velocidade e facilidade de uso, melhorias no monitoramento e administração. É instalar e testar para ver! Em breve detalharei neste espaço as principais novidades deste aguardado release!
Abaixo, os links mais úteis:
* Download
http://www.postgresql.org/download/
* Notas de Lançamento
http://www.postgresql.org/docs/8.4/static/release-8-4.html
* Funções implementadas na versão
http://www.postgresql.org/about/press/features84.html
* Press Release
http://www.postgresql.org/about/press/presskit84.html
terça-feira, 16 de junho de 2009
PostgreSQL 8.4: Release Candidate Liberada!
Depois do teste de softwares em versões beta, a versão Release Candidate é a mais próxima da versão oficial. A poucos minutos a versão RC do PostgreSQL 8.4 foi liberada para download aqui!
Lembro que esta não é uma versão definitiva e não deve ser utilizada em sistemas de produção, mas pode ser utilizada, por exemplo, para o desenvolvimento de produtos enquanto a oficial não chega de fato. Teste e compartilhe suas primeiras impressões!
Lembro que esta não é uma versão definitiva e não deve ser utilizada em sistemas de produção, mas pode ser utilizada, por exemplo, para o desenvolvimento de produtos enquanto a oficial não chega de fato. Teste e compartilhe suas primeiras impressões!
segunda-feira, 15 de junho de 2009
Enquete: Que Prioridades o Desenvolvimento do Postgres deve Assumir?
Que Prioridades o Desenvolvimento do Postgres deve Assumir? Você já pensou nisso?
Essa enquete (What's your highest priority for PostgreSQL development?) está disponível no site da comunidade internacional do PostgreSQL. Se você tem alguma prioridade que não está na lista, podes coloca-l a como comentário.
Fazer acesso à enquete!
Essa enquete (What's your highest priority for PostgreSQL development?) está disponível no site da comunidade internacional do PostgreSQL. Se você tem alguma prioridade que não está na lista, podes coloca-l a como comentário.
Fazer acesso à enquete!
quarta-feira, 10 de junho de 2009
Números Aleatórios com o PostgreSQL: A Função RANDOM()
Gerar números aleatórios é uma necessidade importante para a geração de grandes bases de dados de teste. Para maior veracidade nos testes, uma certa aleatoriedade é esperada deste tipo de base de dados. Aí entram em cena as rotinas de geração de números aleatórios.
A função RANDOM() é o método nativo do PostgreSQL para a geração de seqüências de números aleatórios. Neste post vamos apresentar exemplos práticos do uso desta função que podem ser úteis no cotidiano.
Ao se executar a função RANDOM(), é retornado um número aleatório entre zero e 1 com muitas casas decimais. Dependendo da necessidade, pode-se gerar um número positivo, um valor dentro de um determinado determinado intervalo. Valores e intervalos podem assumir valores nulos e negativos com pequenas variações de sintaxe.
* Sintaxe
1 - A sintaxe básica.
SELECT random();
Retorna: 0.896639783866704, 0.516120770014822...
2 - Busca de números com um valor dentro de um intervalo começado com zero é um pouco mais complicada. O exemplo abaixo retorna um valor entre 0 e 99. Para aumentar ou diminuir o intervalo, trocar o número 100 por outro valor. Ajustar as casas decimais do comando CAST se desejar valores fracionários. A função ROUND() elimina decimais indesejadas.
SELECT round(CAST (random()*100 AS NUMERIC),0);
3 - Busca de números com um valor dentro de um intervalo qualquer demanda atenção. O exemplo abaixo retorna um valor entre 27 e 90. Para aumentar ou diminuir o intervalo, trocar os números 27 e 91 por outros valores. Ajustar as casas decimais do comando CAST se desejar valores fracionários.
SELECT 27 + round(CAST (random()*(91-27) AS NUMERIC),0);
4 - Busca de números com um valor dentro de um intervalo começado com valor negativo. Bastante similar ao exemplo anterior.
SELECT -57 + round(CAST (random()*(91+57) AS NUMERIC),0);
A função RANDOM() é o método nativo do PostgreSQL para a geração de seqüências de números aleatórios. Neste post vamos apresentar exemplos práticos do uso desta função que podem ser úteis no cotidiano.
Ao se executar a função RANDOM(), é retornado um número aleatório entre zero e 1 com muitas casas decimais. Dependendo da necessidade, pode-se gerar um número positivo, um valor dentro de um determinado determinado intervalo. Valores e intervalos podem assumir valores nulos e negativos com pequenas variações de sintaxe.
* Sintaxe
1 - A sintaxe básica.
SELECT random();
Retorna: 0.896639783866704, 0.516120770014822...
2 - Busca de números com um valor dentro de um intervalo começado com zero é um pouco mais complicada. O exemplo abaixo retorna um valor entre 0 e 99. Para aumentar ou diminuir o intervalo, trocar o número 100 por outro valor. Ajustar as casas decimais do comando CAST se desejar valores fracionários. A função ROUND() elimina decimais indesejadas.
SELECT round(CAST (random()*100 AS NUMERIC),0);
3 - Busca de números com um valor dentro de um intervalo qualquer demanda atenção. O exemplo abaixo retorna um valor entre 27 e 90. Para aumentar ou diminuir o intervalo, trocar os números 27 e 91 por outros valores. Ajustar as casas decimais do comando CAST se desejar valores fracionários.
SELECT 27 + round(CAST (random()*(91-27) AS NUMERIC),0);
4 - Busca de números com um valor dentro de um intervalo começado com valor negativo. Bastante similar ao exemplo anterior.
SELECT -57 + round(CAST (random()*(91+57) AS NUMERIC),0);
quarta-feira, 3 de junho de 2009
Geração de CPFs Fictícios com Pl/ PgSQL
A geração de massas de dados para teste é um processo muito importante, para verificar o comportamento de um banco de dados em relação à carga de processamento que o mesmo tem de desempenhar. A geração de CPFs fictícios é uma atividade relativamente comum em empresas brasileiras que armazenam este tipo de identificador. No entanto muitas vezes os testes são feitos com valores incorretos, isto é, que não respeitam as regras para os dois dígitos verificadores.
Abaixo está um código que se propõe a retornar CPFs aleatórios com dígitos verificadores corretos, implementado em Pl/ PgSQL.
Os comandos mais importantes deste código são:
- Random() - Geração de números aleatórios
- substring() - Extração de parte de uma string com base nso parâmetros fornecidos
- CAST () - Conversão de tipos no PostgreSQL
- trim() - Eliminação de espaços em branco de strings
Os testes foram muito positivos. Coloco para você, leitor, as seguintes perguntas:
- Este código segue um algoritmo correto?
- Ele pode ser melhorado? De que forma?
CREATE OR REPLACE FUNCTION gerar_CPF() RETURNS varchar AS $$
-- ROTINA DE GERAÇÃO DE CPF SEM LOOP
-- Retorna string com CPF aletório correto.
DECLARE
vet_cpf integer [11]; --Recebe o CPF
soma integer; -- Soma utilizada para o cálculo do DV
rest integer; -- Resto da divisão
BEGIN
-- Atribuição dos valores do Vetor
vet_cpf[0] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[1] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[2] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[3] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[4] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[5] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[6] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[7] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[8] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
-- CÁLCULO DO PRIMEIRO NÚMERO DO DV
-- Soma dos nove primeiros multiplicados por 10, 9, 8 e assim por diante...
soma:=(vet_cpf[0]*10)+(vet_cpf[1]*9)+(vet_cpf[2]*8)+(vet_cpf[3]*7)+(vet_cpf[4]*6)+(vet_cpf[5]*5)+(vet_cpf[6]*4)+(vet_cpf[7]*3)+(vet_cpf[8]*2);
rest:=soma % 11;
if (rest = 0) or (rest = 1) THEN
vet_cpf[9]:=0;
ELSE vet_cpf[9]:=(11-rest); END IF;
-- CÁLCULO DO SEGUNDO NÚMERO DO DV
-- Soma dos nove primeiros multiplicados por 11, 10, 9 e assim por diante...
soma:= (vet_cpf[0]*11) + (vet_cpf[1]*10) + (vet_cpf[2]*9) + (vet_cpf[3]*8) + (vet_cpf[4]*7) + (vet_cpf[5]*6) + (vet_cpf[6]*5) + (vet_cpf[7]*4) + (vet_cpf[8]*3) + (vet_cpf[9]*2);
rest:=soma % 11;
if (rest = 0) or (rest = 1) THEN
vet_cpf[10] := 0;
ELSE
vet_cpf[10] := (11-rest);
END IF;
--Retorno do CPF
RETURN trim(trim(to_char(vet_cpf[0],'9')) || trim(to_char(vet_cpf[1],'9')) || trim(to_char(vet_cpf[2],'9')) || trim(to_char(vet_cpf[3],'9')) || trim(to_char(vet_cpf[4],'9')) || trim(to_char(vet_cpf[5],'9')) || trim(to_char(vet_cpf[6],'9')) || trim(to_char(vet_cpf[7],'9'))|| trim(to_char(vet_cpf[8],'9')) || trim(to_char(vet_cpf[9],'9')) || trim(to_char(vet_cpf[10],'9')));
END;
$$ LANGUAGE PLPGSQL;
Chamada da função, retornando um CPF aleatório.
select gerar_CPF() ;
A função para fazer o teste está neste post. O resultado para um CPF correto é 1.
select CPF_Validar_Sem_Loop(gerar_CPF());
select CPF_Validar_Sem_Loop('66067526557'); --Gerado pelo programa
Abaixo está um código que se propõe a retornar CPFs aleatórios com dígitos verificadores corretos, implementado em Pl/ PgSQL.
Os comandos mais importantes deste código são:
- Random() - Geração de números aleatórios
- substring() - Extração de parte de uma string com base nso parâmetros fornecidos
- CAST () - Conversão de tipos no PostgreSQL
- trim() - Eliminação de espaços em branco de strings
Os testes foram muito positivos. Coloco para você, leitor, as seguintes perguntas:
- Este código segue um algoritmo correto?
- Ele pode ser melhorado? De que forma?
CREATE OR REPLACE FUNCTION gerar_CPF() RETURNS varchar AS $$
-- ROTINA DE GERAÇÃO DE CPF SEM LOOP
-- Retorna string com CPF aletório correto.
DECLARE
vet_cpf integer [11]; --Recebe o CPF
soma integer; -- Soma utilizada para o cálculo do DV
rest integer; -- Resto da divisão
BEGIN
-- Atribuição dos valores do Vetor
vet_cpf[0] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[1] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[2] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[3] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[4] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[5] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[6] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[7] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
vet_cpf[8] := cast(substring (CAST (random() AS VARCHAR), 3,1) as integer);
-- CÁLCULO DO PRIMEIRO NÚMERO DO DV
-- Soma dos nove primeiros multiplicados por 10, 9, 8 e assim por diante...
soma:=(vet_cpf[0]*10)+(vet_cpf[1]*9)+(vet_cpf[2]*8)+(vet_cpf[3]*7)+(vet_cpf[4]*6)+(vet_cpf[5]*5)+(vet_cpf[6]*4)+(vet_cpf[7]*3)+(vet_cpf[8]*2);
rest:=soma % 11;
if (rest = 0) or (rest = 1) THEN
vet_cpf[9]:=0;
ELSE vet_cpf[9]:=(11-rest); END IF;
-- CÁLCULO DO SEGUNDO NÚMERO DO DV
-- Soma dos nove primeiros multiplicados por 11, 10, 9 e assim por diante...
soma:= (vet_cpf[0]*11) + (vet_cpf[1]*10) + (vet_cpf[2]*9) + (vet_cpf[3]*8) + (vet_cpf[4]*7) + (vet_cpf[5]*6) + (vet_cpf[6]*5) + (vet_cpf[7]*4) + (vet_cpf[8]*3) + (vet_cpf[9]*2);
rest:=soma % 11;
if (rest = 0) or (rest = 1) THEN
vet_cpf[10] := 0;
ELSE
vet_cpf[10] := (11-rest);
END IF;
--Retorno do CPF
RETURN trim(trim(to_char(vet_cpf[0],'9')) || trim(to_char(vet_cpf[1],'9')) || trim(to_char(vet_cpf[2],'9')) || trim(to_char(vet_cpf[3],'9')) || trim(to_char(vet_cpf[4],'9')) || trim(to_char(vet_cpf[5],'9')) || trim(to_char(vet_cpf[6],'9')) || trim(to_char(vet_cpf[7],'9'))|| trim(to_char(vet_cpf[8],'9')) || trim(to_char(vet_cpf[9],'9')) || trim(to_char(vet_cpf[10],'9')));
END;
$$ LANGUAGE PLPGSQL;
Chamada da função, retornando um CPF aleatório.
select gerar_CPF() ;
A função para fazer o teste está neste post. O resultado para um CPF correto é 1.
select CPF_Validar_Sem_Loop(gerar_CPF());
select CPF_Validar_Sem_Loop('66067526557'); --Gerado pelo programa
quarta-feira, 13 de maio de 2009
PostgreSQL no IV Festival Software Livre da Bahia
Eventos de software livre ganham maior relevância, à medida em que se consolidam. O III ENSL - Encontro Nordestino de Software Livre e o IV Festival Software Livre da Bahia, que antes eram iniciativas distintas, se fundiram em um único evento que será realizado nos dias 29 e 30 de maio de 2009, no campus da Universidade Estadual da Bahia (UNEB), em Salvador.
A programação é vasta e eclética e abrange cinco grandes áreas: Cultura Digital Livre; Casos de Sucesso; Ferramentas e Soluções; Desenvolvimento de Software e Educação e Inclusão Digital.
O PostgreSQL será discutido na palestra "Tuning de Banco de Dados Livre: O Caso do PostgreSQL", ministrada por mim.
A programação detalhada e as inscrições estão disponíveis até 24/05 no site do evento!
A programação é vasta e eclética e abrange cinco grandes áreas: Cultura Digital Livre; Casos de Sucesso; Ferramentas e Soluções; Desenvolvimento de Software e Educação e Inclusão Digital.
O PostgreSQL será discutido na palestra "Tuning de Banco de Dados Livre: O Caso do PostgreSQL", ministrada por mim.
A programação detalhada e as inscrições estão disponíveis até 24/05 no site do evento!
terça-feira, 28 de abril de 2009
A Oracle comprou a SUN e conseqüentemente o Java e o MySQL. E como fica o PostgreSQL?
A Oracle comprou a SUN e conseqüentemente o Java e o MySQL. Mais informações podem ser obtidas aqui. Que impactos esta aquisição causará sobre o PostgreSQL?
Ainda é muito cedo para ter certezas sobre este tema, mas ele certamente é bastante crítico para a área de banco de dados. A Oracle adquiriu nos últimos anos uma série de empresas e seus softwares de banco, dentre elas o Berkeley DB, que passaram a figurar entre as soluções desta empresa. As novas aquisições continuarão a ser livres e a serem aprimoradas? O suporte do java ao PostgreSQL estará ameaçado? O espaço para o PostgreSQL diminuirá ou será ampliado? Estas e outras questões permanecem em aberto.
Baseado nestas dúvidas tive a idéia de criar um tópico aberto. Peço que coloquem opiniões e links para reportagens sobre o impacto desta aquisição para a comunidade de banco de dados e particularmente para os usuários do PostgreSQL.
Atualização (13/05/2009): anexo link para posts sobre o assunto no site do Fernando Ike e do Telles.
Ainda é muito cedo para ter certezas sobre este tema, mas ele certamente é bastante crítico para a área de banco de dados. A Oracle adquiriu nos últimos anos uma série de empresas e seus softwares de banco, dentre elas o Berkeley DB, que passaram a figurar entre as soluções desta empresa. As novas aquisições continuarão a ser livres e a serem aprimoradas? O suporte do java ao PostgreSQL estará ameaçado? O espaço para o PostgreSQL diminuirá ou será ampliado? Estas e outras questões permanecem em aberto.
Baseado nestas dúvidas tive a idéia de criar um tópico aberto. Peço que coloquem opiniões e links para reportagens sobre o impacto desta aquisição para a comunidade de banco de dados e particularmente para os usuários do PostgreSQL.
Atualização (13/05/2009): anexo link para posts sobre o assunto no site do Fernando Ike e do Telles.
quinta-feira, 16 de abril de 2009
Versão 8.4: primeira release beta disponível!
O grupo de desenvolvimento do PostgreSQL anunciou que a primeira versão 8.4 BETA está disponível para download. A colaboração da comunidade nos testes é de vital importância para o diagnóstico e correção de quaisquer problemas na ferramenta. Esta versão não deve ser utilizada para aplicações corporativas, por ser menos estável que as releases padrão.
Testemos, critiquemos e participemos!!!
Mais informações em: http://www.postgresql.org/developer/beta.
Em breve apresentaremos um detalhamento das novas funcionalidades da versão 8.4 neste espaço.
Testemos, critiquemos e participemos!!!
Mais informações em: http://www.postgresql.org/developer/beta.
Em breve apresentaremos um detalhamento das novas funcionalidades da versão 8.4 neste espaço.
quarta-feira, 8 de abril de 2009
Fique Atualizado em PostgreSQL com o Addict-o-matic!!!
Ficar atualizado em tecnologias de hardware e software não é das tarefas mais fáceis. O site Addict-o-matic faz a coleta de uma série de notícias, posts em blogs, vídeos e imagens em uma série de fontes na rede. O resultado de uma pesquisa sobre o PostgreSQL não decepcionou.
Clique aqui para experimentar! Podem ser fornecidas várias opções de pesquisa, e o site funciona bem como agregador de informações.
A dica do site foi do blog da colunista Sandra Carvalho.
Clique aqui para experimentar! Podem ser fornecidas várias opções de pesquisa, e o site funciona bem como agregador de informações.
A dica do site foi do blog da colunista Sandra Carvalho.
sexta-feira, 3 de abril de 2009
Ano Bissexto no PostgreSQL!
Às vezes o mais difícil de fazer são coisas realmente simples. Os exemplo de código abaixo são implementações de uma rotina que calcula se um ano é bissexto ou não.
Segundo a Wikipedia, as regras do ano bissexto são poucas, mas não são triviais:
* São bissextos todos os anos múltiplos de 400, p.ex: 1600, 2000, 2400, 2800
* Não são bissextos todos os múltiplos de 100 e não de 400, p.ex: 1700, 1800, 1900, 2100, 2200, 2300, 2500...
* São bissextos todos os múltiplos de 4 e não múltiplos de 100, p.ex: 1996, 2004, 2008, 2012, 2016...
* Não são bissextos todos os demais anos.
Com base no que é apresentado neste post, peço que você que me responda três perguntas:
- Os dois exemplos abaixo estão corretos?
- Qual dos dois apresentaria alguma vantagem em relação ao outro? Ou são ambos equivalentes?
- É possível melhorar as implementações? De que formas?
As duas funções criadas retornam 1 se ano for bissexto, 0 se não for e 99 se for anterior a 1582, para anos acima de 1582.
Exemplo 1:
CREATE OR REPLACE FUNCTION ano_bissexto (pAno integer) RETURNS integer AS $$
DECLARE
ret integer;
BEGIN
IF $1<1582 THEN RETURN 99; END IF;
ret :=0; --Inicialização
IF ($1%400=0) THEN
ret:=1; /*Bissexto*/
ELSE
IF ($1%4=0) AND ($1%100<>0) THEN
ret:=1; /*Bissexto*/
END IF;
END IF;
RETURN ret;
END;
$$ LANGUAGE plpgsql;
SELECT ano_bissexto(1600);
Exemplo 2:
CREATE OR REPLACE FUNCTION ano_bissexto_menor (pAno integer) RETURNS integer AS $$
DECLARE
ret integer;
BEGIN
IF $1<1582 THEN RETURN 99; END IF;
ret :=$1; --Inicialização
IF (ret%100=0) THEN
ret:=ret/100;
END IF;
IF ret%4=0 THEN
RETURN 1; --Bissexto
ELSE
RETURN 0;
END IF;
END;
$$ LANGUAGE plpgsql;
SELECT ano_bissexto_menor(1600);
Segundo a Wikipedia, as regras do ano bissexto são poucas, mas não são triviais:
* São bissextos todos os anos múltiplos de 400, p.ex: 1600, 2000, 2400, 2800
* Não são bissextos todos os múltiplos de 100 e não de 400, p.ex: 1700, 1800, 1900, 2100, 2200, 2300, 2500...
* São bissextos todos os múltiplos de 4 e não múltiplos de 100, p.ex: 1996, 2004, 2008, 2012, 2016...
* Não são bissextos todos os demais anos.
Com base no que é apresentado neste post, peço que você que me responda três perguntas:
- Os dois exemplos abaixo estão corretos?
- Qual dos dois apresentaria alguma vantagem em relação ao outro? Ou são ambos equivalentes?
- É possível melhorar as implementações? De que formas?
As duas funções criadas retornam 1 se ano for bissexto, 0 se não for e 99 se for anterior a 1582, para anos acima de 1582.
Exemplo 1:
CREATE OR REPLACE FUNCTION ano_bissexto (pAno integer) RETURNS integer AS $$
DECLARE
ret integer;
BEGIN
IF $1<1582 THEN RETURN 99; END IF;
ret :=0; --Inicialização
IF ($1%400=0) THEN
ret:=1; /*Bissexto*/
ELSE
IF ($1%4=0) AND ($1%100<>0) THEN
ret:=1; /*Bissexto*/
END IF;
END IF;
RETURN ret;
END;
$$ LANGUAGE plpgsql;
SELECT ano_bissexto(1600);
Exemplo 2:
CREATE OR REPLACE FUNCTION ano_bissexto_menor (pAno integer) RETURNS integer AS $$
DECLARE
ret integer;
BEGIN
IF $1<1582 THEN RETURN 99; END IF;
ret :=$1; --Inicialização
IF (ret%100=0) THEN
ret:=ret/100;
END IF;
IF ret%4=0 THEN
RETURN 1; --Bissexto
ELSE
RETURN 0;
END IF;
END;
$$ LANGUAGE plpgsql;
SELECT ano_bissexto_menor(1600);
quinta-feira, 2 de abril de 2009
Enquete Encerrada: PostgreSQL é um Ótimo Nome para Banco de Dados!
A enquete que perguntava a respeito do nome do PostgreSQL foi encerrada, e foi considerado que o nome tradicional deve ser mantido por uma maioria esmagadora. Os nomes alternativos sugeridos não tiveram aceitação e a opção de outros nomes não foi acolhida. Abaixo, os dados:
Opção | Votos | Percentual |
Deve ser mantido. | 152 | 69,72 |
Que tal PgDB? | 15 | 6,88 |
Postgree seria melhor | 35 | 16,06 |
Outro | 9 | 4,13 |
Não sei. | 7 | 3,21 |
Totais | 218 | 100 |
Concorda com o resultado? Discorda? Deixe seu comentário!
sexta-feira, 27 de março de 2009
Log com Arquivos CSV
Arquivos texto são muito utilizados em sistemas de informação. No entanto, sua manipulação automática muitas vezes é difícil por serem meios não estruturados de armazenamento de informações. O uso de arquivos CSV (Comma-Separated-Values - arquivos com valores separados por vírgula) facilita a utilização de arquivos texto para o armazenamento de dados. Um dos usos de arquivos CSV é no armazenamento do log de bancos de dados PostgreSQL, que passa a ser mais facilmente tratado por meio de planilhas eletrônicas, que apresentam os itens do log de forma tabular.
A utilização de log em arquivo CSV é muito simples, bastando se alterar o arquivo POSTGRESQL.CONF, alterando o parâmetro log_destination, e fazer o reload da configuração. Comente o valor anterior do parâmetro e coloque esta linha:
log_destination = 'csvlog'
A partir deste momento os arquivos de log criados serão do tipo CSV. Abaixo, uma imagem ilustrando como fica armazenado fisicamente o log:
A utilização de log em arquivo CSV é muito simples, bastando se alterar o arquivo POSTGRESQL.CONF, alterando o parâmetro log_destination, e fazer o reload da configuração. Comente o valor anterior do parâmetro e coloque esta linha:
log_destination = 'csvlog'
A partir deste momento os arquivos de log criados serão do tipo CSV. Abaixo, uma imagem ilustrando como fica armazenado fisicamente o log:
segunda-feira, 16 de março de 2009
Que linguagem você utiliza com o PostgreSQL?
Que linguagem você utiliza com o PostgreSQL? Esta é a enquete atual do site do PostgreSQL. Participe!
www.postgresql.org/community
www.postgresql.org/community
quarta-feira, 11 de março de 2009
Possíveis Funcionalidades das Versões Futuras do PostgreSQL
Pouco se sabe ainda das novas funcionalidades a serem implementadas na versão 8.4 do PostgreSQL. Recentemente, uma apresentação recente de Bruce Momjian apresentou uma descrição de algumas das principais alterações em implementação. As funcionalidades prometem melhor desempenho e facilidade em certos tipos de consulta.
Algumas das principais alterações da versão 8.4 seriam:
- Column-Level Permissions - Permissões de acesso em por coluna.
- Windowing Functions: Sum and Rank - Ranqueamento de registros e somatório em uma sintaxe simples.
- WITH Queries: Simple and Recursive - sintaxe alternativa para a realização de consultas, inclusive permitindo recursividade.
- Parallel Restore of Dumps - Uso de threads para ganhar paralelismo na restauração de backups. Deve depender do sistema operacjional para funcionar.
- Visibility Maps Reduce Vacuum Overhead - Aprimoramento do desempenho das rotinas de Vacuum.
- No Need for Free-Space Map Configuration - Remoção de configurações dos arquivos de configuração.
- Default Values for Function Arguments - Funções com valores DEFAULT para retorno.
- Outras alterações, principalmente voltadas para o desempenho.
Confira as alterações segundo o texto original aqui.
Esta informação foi obtida no blog do Guedes.
Algumas das principais alterações da versão 8.4 seriam:
- Column-Level Permissions - Permissões de acesso em por coluna.
- Windowing Functions: Sum and Rank - Ranqueamento de registros e somatório em uma sintaxe simples.
- WITH Queries: Simple and Recursive - sintaxe alternativa para a realização de consultas, inclusive permitindo recursividade.
- Parallel Restore of Dumps - Uso de threads para ganhar paralelismo na restauração de backups. Deve depender do sistema operacjional para funcionar.
- Visibility Maps Reduce Vacuum Overhead - Aprimoramento do desempenho das rotinas de Vacuum.
- No Need for Free-Space Map Configuration - Remoção de configurações dos arquivos de configuração.
- Default Values for Function Arguments - Funções com valores DEFAULT para retorno.
- Outras alterações, principalmente voltadas para o desempenho.
Confira as alterações segundo o texto original aqui.
Esta informação foi obtida no blog do Guedes.
sexta-feira, 13 de fevereiro de 2009
Documentando Objetos no PostgreSQL
Onde guardar a documentação sobre os objetos do seu banco de dados? A importância a e grande quantidade de informação sobre tabelas, seus campos, índices e outros objetos faz com que essa questão ganhe importância. Um bom lugar para fazer esse registro é justamente o próprio banco de dados. No PostgreSQL é possível se comentar os objetos armazenados no banco, atualizar, remover e consultar essas informações, através do comando COMMENT.
O comando COMMENT armazena um comentário textual associado a um objeto do banco de dados. Sua sintaxe é relativamente simples:
A grande lista de tipos de objetos para os quais o comando pode criar comentários é bastante abrangente. Compreende tabelas, campos de tabelas, índices, tablespaces, esquemas, databases, tipos, funções, etc. Os comentários são armazenados em campos TEXT, que permitem documentações largamente detalhadas.
Os comentários são consultados por meio do utilitário PSQL e de algumas funções disponibilizadas pelo PostgreSQL (
create table starttest (col int);
create table starttest2 (col int);
2 - Definição de Comentários
COMMENT ON TABLE starttest IS 'Tabela do sistema SITP';
COMMENT ON TABLE starttest2 IS 'SITP - Modulo II';
3 - Remoção de Comentários
COMMENT ON TABLE starttest IS NULL;
1 - Recuperação de OID de objeto em PG_CLASS.
SELECT relname, relfilenode
FROM PG_CLASS
WHERE relname LIKE 'starttest%';
2 - Consulta dos commentários associados pelo OID.
SELECT obj_description(17173);
3 - Consulta dos comentários de todos os objetos de PG_CLASS.
SELECT obj_description(p.relfilenode), * from pg_class p;
4 - Consulta dos comentários de todos os objetos de PG_TYPE.
SELECT obj_description(p.typrelid), * from PG_TYPE p;
O uso do comando COMMENT para documentar objetos do banco é pouco difundido em parte pelo fato do mesmo ser pouco conhecido, não apresentar similares em alguns SGBDs e por não ser gerado por muitas das ferramentas do mercado, que armazenam estas informações em formato próprio, sem transferi-las ao SGBD.
Também existem questões de segurança, pois um usuário malicioso que tenha acesso ao banco pode recuperar os comentários sobre os seus objetos. No entanto, o interesse real dos invasores de bancos de dados se refere às informações armazenadas, e não à documentação dos bancos de dados.
Deve ser evitado armazenar qualquer informação crítica para a segurança com o comando COMMENT, tais como senhas, informações sobre criptografia e política de acesso utilizados, uma vez que não existem restrições de segurança para os comentários armazenados, isto é, qualquer usuário criado no SGBD visualiza todas as informações.
Os comentários são exportados ao se fazer um backup do banco com os utilitários do PostgreSQL.
O comando COMMENT armazena um comentário textual associado a um objeto do banco de dados. Sua sintaxe é relativamente simples:
COMMENT ON
{
TABLE object_name |
COLUMN table_name.column_name |
AGGREGATE agg_name (agg_type [, ...] ) |
CAST (sourcetype AS targettype) |
CONSTRAINT constraint_name ON table_name |
CONVERSION object_name |
DATABASE object_name |
DOMAIN object_name |
FUNCTION func_name ( [ [ argmode ] [ argname ] argtype [, ...] ] ) |
INDEX object_name |
LARGE OBJECT large_object_oid |
OPERATOR op (leftoperand_type, rightoperand_type) |
OPERATOR CLASS object_name USING index_method |
OPERATOR FAMILY object_name USING index_method |
[ PROCEDURAL ] LANGUAGE object_name |
ROLE object_name |
RULE rule_name ON table_name |
SCHEMA object_name |
SEQUENCE object_name |
TABLESPACE object_name |
TEXT SEARCH CONFIGURATION object_name |
TEXT SEARCH DICTIONARY object_name |
TEXT SEARCH PARSER object_name |
TEXT SEARCH TEMPLATE object_name |
TRIGGER trigger_name ON table_name |
TYPE object_name |
VIEW object_name
} IS 'text'
A grande lista de tipos de objetos para os quais o comando pode criar comentários é bastante abrangente. Compreende tabelas, campos de tabelas, índices, tablespaces, esquemas, databases, tipos, funções, etc. Os comentários são armazenados em campos TEXT, que permitem documentações largamente detalhadas.
Os comentários são consultados por meio do utilitário PSQL e de algumas funções disponibilizadas pelo PostgreSQL (
obj_description
, col_description
, and shobj_description
).- Exemplos de Código - Criação de Comentário
create table starttest (col int);
create table starttest2 (col int);
2 - Definição de Comentários
COMMENT ON TABLE starttest IS 'Tabela do sistema SITP';
COMMENT ON TABLE starttest2 IS 'SITP - Modulo II';
3 - Remoção de Comentários
COMMENT ON TABLE starttest IS NULL;
- Exemplos de Código - Consulta de Comentários
1 - Recuperação de OID de objeto em PG_CLASS.
SELECT relname, relfilenode
FROM PG_CLASS
WHERE relname LIKE 'starttest%';
2 - Consulta dos commentários associados pelo OID.
SELECT obj_description(17173);
3 - Consulta dos comentários de todos os objetos de PG_CLASS.
SELECT obj_description(p.relfilenode), * from pg_class p;
4 - Consulta dos comentários de todos os objetos de PG_TYPE.
SELECT obj_description(p.typrelid), * from PG_TYPE p;
- Utilizaçao Prática
O uso do comando COMMENT para documentar objetos do banco é pouco difundido em parte pelo fato do mesmo ser pouco conhecido, não apresentar similares em alguns SGBDs e por não ser gerado por muitas das ferramentas do mercado, que armazenam estas informações em formato próprio, sem transferi-las ao SGBD.
Também existem questões de segurança, pois um usuário malicioso que tenha acesso ao banco pode recuperar os comentários sobre os seus objetos. No entanto, o interesse real dos invasores de bancos de dados se refere às informações armazenadas, e não à documentação dos bancos de dados.
Deve ser evitado armazenar qualquer informação crítica para a segurança com o comando COMMENT, tais como senhas, informações sobre criptografia e política de acesso utilizados, uma vez que não existem restrições de segurança para os comentários armazenados, isto é, qualquer usuário criado no SGBD visualiza todas as informações.
Os comentários são exportados ao se fazer um backup do banco com os utilitários do PostgreSQL.
quarta-feira, 28 de janeiro de 2009
Configuração Básica de Driver ODBC para PostgreSQL
Acesso a dados demanda um bom middleware. E a tecnologia ODBC - Open Database Connectivity, é uma opção bastante estável, disponível desde 1992. Por apresentar drivers para praticamente todos os bons SGBDs do mercado, muitas soluções são implementadas utilizando esta tecnologia.
O suporte às funcionalidades de um SGBD relacional e a grande disponibilidade de drivers são grandes pontos fortes deste middleware. Como problemas podem ser elencadas a falta de atualizações recentes, com defasagem em termos de novas funcionalidades oferecidas por outros componentes de acesso a dados e o fato de ser uma tecnologia proprietária.
Longe de esgotar este tópico, este post mostra uma configuração básica de ODBC para PostgreSQL, como a que foi utilizada para a utilização da ferramenta DbDesigner Fork.
* Etapa 1- Instalação
É sempre recomendável baixar a versão mais atualizada disponível, no site da comunidade PostgreSQL.ORG: http://www.postgresql.org/ftp/odbc/versions/
No nosso caso, a instalação será feita em uma máquina com Windows XP. Existem formas de utilizar o ODBC no Linux e no UNIX e meios de se fazer pontes envolvendo ODBC e JDBC, mas estas variações estão (bastante) fora do escopo deste post.
Descompacte o arquivo ZIP e execute o instalador. É sempre aconselhável ler antes o arquivo readme e se for uma atualização, pode ser disparado o arquivo upgrade.bat. Na instalação padrão um assistente relativamente simples se encarregará do processo sem que se precise fazer configurações complicadas.
* Etapa 2 - Configuração
Após a instalação, abra o painel de controle do windows (Menu Iniciar/ Painel de Controle). Dispare a opção "Ferramentas administrativas" e depois selecione "Fontes de Dados (ODBC)".
Será aberta a tela "Administrador de Fonte de Dados ODBC". Nesta tela, selecione a aba "Drivers ODBC que estão instalados no sistema". Observe na imagem abaixo que foram instalados os drivers para PostgreSQL ANSI e UNICODE.
Para criar um data source, selecione a aba "Fonte de dados do usuário" e o botão "Adicionar". Aparecerá uma tela como a que está abaixo. Selecione o driver do PostgreSQL e confirme.
Em seguida, preencha os valores para o nome da fonte (Description), banco de dados para o qual aponta (Database), servidor em que está o banco de dados (Server), Porta de Comunicação (Port), usuário e senha. O servidor pode assumir os valores "localhost" ou um endereço IP. Utilize o botão TEST para verificar se os dados foram devidamente fornecidos e se a conexão pode ser feita e a opção SAVE para gravar a configuração do driver.
A opção "Configurar" permite a alteração de uma fonte de dados do usuário, abrindo a tela abaixo. Os botões Datasource, Global e Manage DSN estão fora do escopo deste post.
Após fazer a instalação, a nova fonte de dados do usuário aparece na lista, podendo ser utilizada por várias aplicações compatíveis com o ODBC.
Mais informações sobre ODBC podem ser obtidas nestas fontes:
- Na Wikipedia
- Site Easysoft, com informações sobre ODBC em UNIX e Linux
O suporte às funcionalidades de um SGBD relacional e a grande disponibilidade de drivers são grandes pontos fortes deste middleware. Como problemas podem ser elencadas a falta de atualizações recentes, com defasagem em termos de novas funcionalidades oferecidas por outros componentes de acesso a dados e o fato de ser uma tecnologia proprietária.
Longe de esgotar este tópico, este post mostra uma configuração básica de ODBC para PostgreSQL, como a que foi utilizada para a utilização da ferramenta DbDesigner Fork.
* Etapa 1- Instalação
É sempre recomendável baixar a versão mais atualizada disponível, no site da comunidade PostgreSQL.ORG: http://www.postgresql.org/ftp/odbc/versions/
No nosso caso, a instalação será feita em uma máquina com Windows XP. Existem formas de utilizar o ODBC no Linux e no UNIX e meios de se fazer pontes envolvendo ODBC e JDBC, mas estas variações estão (bastante) fora do escopo deste post.
Descompacte o arquivo ZIP e execute o instalador. É sempre aconselhável ler antes o arquivo readme e se for uma atualização, pode ser disparado o arquivo upgrade.bat. Na instalação padrão um assistente relativamente simples se encarregará do processo sem que se precise fazer configurações complicadas.
* Etapa 2 - Configuração
Após a instalação, abra o painel de controle do windows (Menu Iniciar/ Painel de Controle). Dispare a opção "Ferramentas administrativas" e depois selecione "Fontes de Dados (ODBC)".
Será aberta a tela "Administrador de Fonte de Dados ODBC". Nesta tela, selecione a aba "Drivers ODBC que estão instalados no sistema". Observe na imagem abaixo que foram instalados os drivers para PostgreSQL ANSI e UNICODE.
Para criar um data source, selecione a aba "Fonte de dados do usuário" e o botão "Adicionar". Aparecerá uma tela como a que está abaixo. Selecione o driver do PostgreSQL e confirme.
Em seguida, preencha os valores para o nome da fonte (Description), banco de dados para o qual aponta (Database), servidor em que está o banco de dados (Server), Porta de Comunicação (Port), usuário e senha. O servidor pode assumir os valores "localhost" ou um endereço IP. Utilize o botão TEST para verificar se os dados foram devidamente fornecidos e se a conexão pode ser feita e a opção SAVE para gravar a configuração do driver.
A opção "Configurar" permite a alteração de uma fonte de dados do usuário, abrindo a tela abaixo. Os botões Datasource, Global e Manage DSN estão fora do escopo deste post.
Após fazer a instalação, a nova fonte de dados do usuário aparece na lista, podendo ser utilizada por várias aplicações compatíveis com o ODBC.
Mais informações sobre ODBC podem ser obtidas nestas fontes:
- Na Wikipedia
- Site Easysoft, com informações sobre ODBC em UNIX e Linux
quarta-feira, 14 de janeiro de 2009
Power Architect - Ótima Ferramenta Livre!!!
Falar de ferramentas de banco de dados geralmente implica em destacar suas limitações. Uma exceção é o Power Architect, que apresenta boas e úteis funcionalidades para o desenvolvimento de aplicações que tenham um certo grau de complexidade. É uma ferramenta livre e de código aberto, cujo download pode ser feito aqui.
Não é exclusiva para o PostgreSQL, podendo também ser utilizada em projetos com Oracle, SQL Server, MySQL, Derby e HSQLDB. O desenvolvimento é pago por taxa de suporte premium de 199 dólares ao ano, o que é relativamente baixo em se falando de ferramentas de base de dados.
As principais funcionalidades são:
Alguns problemas ou desvantagens foram constatados. Falta suporte a visões, triggers, restrições tipo check e stored procedures, recursos importantes para o projeto de bancos de dados de maior complexidade. Outros problemas menores constatados foram: falta Suporte a trabalho em grupos, ausência de Controle de versões e falta de interface WEB.
Abaixo, algumas telas capturadas:
* Avaliação Geral
A ferramenta é superior ao DBDesigner e pode ser utilizada para projetos que não sejam de pequeno porte. Apresentou poucos bugs nos testes realizados. No entanto, as desvantagens apesar de poucas são significativas.
Não é exclusiva para o PostgreSQL, podendo também ser utilizada em projetos com Oracle, SQL Server, MySQL, Derby e HSQLDB. O desenvolvimento é pago por taxa de suporte premium de 199 dólares ao ano, o que é relativamente baixo em se falando de ferramentas de base de dados.
As principais funcionalidades são:
- Boa interface visual com diagramas de ER e OLAP
- Acesso a bancos de dados via JDBC
- Conexão a múltiplas fntes de dados ao mesmo tempo
- Comparação de modelos de dados com identificação de diferenças e geração de scripts de sincronização
- Suporte a "Drag-and-drop" de tabelas de um modelo para o playpen (diagrama)
- Geração de banco de dados através do projeto (Forward-engineers)
- Engenharia reversa para a construção dos projetos
- Salvamento da estrutura de dados em um projeto que pode ser trabalhado remotemante
- Dados do projeto armazenados em um formato XML de fácil navegação
- Licença livre GPL (version 3)
- Suporte rudimentar a ETL - Extração, Transformação e Carga de Dados
- Suporte a esquemas OLAP para projeto de Data Warehouses
Alguns problemas ou desvantagens foram constatados. Falta suporte a visões, triggers, restrições tipo check e stored procedures, recursos importantes para o projeto de bancos de dados de maior complexidade. Outros problemas menores constatados foram: falta Suporte a trabalho em grupos, ausência de Controle de versões e falta de interface WEB.
Abaixo, algumas telas capturadas:
- Tela de conexão a banco de dados PostgreSQL, tendo ao fundo uma visão geral da ferramenta.
- Parâmetros para a comparação entre bancos de dados
- Tela de resultado da comparação entre bancos de dados.
* Avaliação Geral
A ferramenta é superior ao DBDesigner e pode ser utilizada para projetos que não sejam de pequeno porte. Apresentou poucos bugs nos testes realizados. No entanto, as desvantagens apesar de poucas são significativas.
segunda-feira, 12 de janeiro de 2009
PostgreSQL: primeira release de 2009!!!
A equipe do PostgreSQL lançou a primeira release de 2009, apresentando uma versão instável que não deve ser utilizada para ambientes de produção, que consiste basicamente em uma visão snapshot das atualizações feitas no desenvolvimento do banco. O instalador pode ser baixado aqui. A documentação desta versão está disponível aqui, mas não conta por exemplo com uma seção "release notes" apesar de apreentar no título referência à versão 8.4.
É uma boa opção para desenvolvedores e testadores que querem se antecipar às novas funcionalidades da versão 8.4 que estão em desenvolvimento ou colaborar nos testes.
Acredita-se que no primeiro semestre serão lançadas as primeiras versões de teste para a nova release 8.4 deste SGBD.
É uma boa opção para desenvolvedores e testadores que querem se antecipar às novas funcionalidades da versão 8.4 que estão em desenvolvimento ou colaborar nos testes.
Acredita-se que no primeiro semestre serão lançadas as primeiras versões de teste para a nova release 8.4 deste SGBD.
Assinar:
Postagens (Atom)