Página pessoal de André Fernandes

Comecei com o postgresql de uma forma muito particular, nem desejava ser DBA na época. Hoje não somente trabalho com postgresql, como também adoro o que faço, não têm banco.de dados que me agrade mais de que postgresql; Oracle, Sql Server, DB2, firebird, nenhum deles tem o “sabor” do postgresql.
Quando observo o mercado, preocupo-me quanto à minha.escolha, vejo vagas aos montes para especialistas em Sql Server, em Oracle database, mas poucas para quem é especialista em postgresql como eu.
Deveria eu mudar de especialidade? Deverei especializar-me em Oracle? Ou em Sql Server? Honestamente não sei, preciso tomar uma toda logo, ficar com o que gosto ou mudar de barco.
Ainda.que postgresql tenha seus defeitos, é fantástico, não vejo como pensar em usar outro gerenciador de banco de dados a não ser em algumas poucas exceções, e a cada nova versão do postgresql menor o número de exceções.
Vale ainda a pena dedicar-me profissionalmente ao pg?

Tags: PostgreSQL

Outra forma de mostrar a descrição de uma função em postgreSQL é

SELECT pg_get_functiondef(oid) FROM pg_proc WHERE proname ilike 'nome_funcao';

Nota: trocar nome_funcao pelo nome da função desejada.

Abraços!

Tags: função, function, plpgsql, PostgreSQL

ArchLinux. Quando falaram desta distribuição linux, pensei ser mais uma distribuição que poderia até ser interessante, mas nada demais.
Felizmente eu estava muito errado! ArchLinux mantém o KISS (Keep It Simple, Stupid) do Slackware, um sistema tão eficiente de pacotes e sources como o Freebsd, muito rápido para instalar, com grande fonte de ajuda que é a sua wiki-página. Quase tudo são elogios.
Agora, um detalhe, não recomendo esta distribuição para quem não conhece linux. Pelo menos um pouco tem de saber ou não vai sair do lugar. A instalação ainda não é tão intuitiva quanto a do Slackware e instala apenas o básico, mas o sistema de pacotes pacman é um show!
A estabilidade até o momento não descepcionou, tudo tem sido excelente, e estou usando há mais de 3 meses sem problemas – salvo quando resolvi fazer algo sem antes consultar a wiki da distribuição, ali tinha a resposta para todos os problemas que eu estava encontrando.
Recomendo a todos que gostem de linux como eu! Vale a pena!

Tags: Arch Linux, ArchLinux, linux

Para obter o código de uma função em Postgresql, podemos usar de pequenos artifícios (lembre-se de trocar #nome_da_funcao# pelo nome da função em questão:

1) se estivermos no psql, podemos rodar

\df+ #nome_da_funcao#

ou

\ef #nome_da_funcao#

sendo que na segunda opção(\ef) estaremos editando o código no editor padrão e não apenas vendo o código da função, enquanto na primeira opção(\df+) teremos mais dados além do código da função.

2) se não estivermos no psql, ou se quisermos apenas listar o código da função, podemos rodar uma consulta simples:

SELECT pg_catalog.pg_get_functiondef('#nome_da_funcao#'::regprocedure);

Exemplo:

SELECT pg_catalog.pg_get_functiondef('apagar_usuarios_inativos()'::regprocedure);

Espero que seja de ajuda para alguém,
abraços!

Tags: função, function, plpgsql, PostgreSQL

Bom dia!

Você sabe o que é Latex? E tex?

Tex e Latex são “processadores de texto” que servem para criarmos documentos com qualidade de impressão superior. No entanto, é bem diferente trabalhar com tex ou latex de que trabalhar com o libreoffice ou com o MS Word®, pois escrever um texto neles parece mais com programação de que com escrever um texto a primeira vista.

Na realidade, podemos dividir os “processadores de texto” em duas categorias:

1) visuais, onde você já vê como ficará o seu documento a medida em que escreve o mesmo, sem precisar de nenhuma etapa adicional (como compilar o mesmo). Nesta categoria estão o libreoffice, o MS Word®, abiword, entre outros.

2) compiláveis, onde você descreve logicamente como deve ser o documento em uma linguagem pré-definida e, a partir de um processo chamado de compilação, você obtem o documento final formatado e pronto (por exemplo, em PDF). Nesta categoria está o Latex (e o tex também).

Mas por quê usar uma linguagem assim, deves estar se perguntando, se podemos usar o Word, por exemplo? A resposta a esta pergunta é simples (embora demore um pouco para convencer-se disso (para mim pelo menos demorou um pouco): a qualidade final do documento produzido, em geral, é muito superior à qualidade obtida em editores de texto visuais.

Bom, deves estar se perguntando como é a cara de um documento latex, estou certo? Vejamos um exemplo bem simples:

% Aqui comecamos a dizer a formatação de nosso documento
\documentclass[a4paper, 10pt]{report}
\usepackage[brazil]{babel}
% Aqui comeca o documento em si, ou seja, o texto propriamente dito
\begin{document}
Bem vindo ao mundo de Latex!
\end{document} 

Podemos reparar que o documento tem duas áreas bem distintas: a primeira, onde apenas dizemos sobre a formatação geral do documento, é chamada de Preâmbulo, a segunda, onde temos o texto em si, é chamada (adivinhem!) de Texto.

Como já deves ter imaginado, toda linha começada por % é uma linha de comentários.

Agora vejamos que na linha após o comentário inicial temos outra linha no formato:

\documentclass[OPCOES]{ESTILO}

Esta linha deve existir em todos os documentos feitos em latex.

O estilo é como se fosse um marcador de qual o tipo de documento sendo desenvolvido. Os estilos mais comuns são:

• article   (para artigos em revistas)
• book  (para livros)
• letter  (para cartas)
• report  (para relatórios científicos (ou nem tanto… )
• slides  (para apresentações)

Agora, as opções podem ser de vários tipos e devem estar separadas por vírgula. No nosso exemplo usamos um tipo (tamanho) de papel e um tamanho de fonte. As opções mais comuns são:

• tamanho da letra: 10pt, 11pt ou 12pt.
• tamanho (tipo) de papel: a4paper, a5paper, b5paper, executivepaper, legalpaper  ou letterpaper.
• orientação da página: portrait(sem colocar opção de landscape) ou landscape (paisagem).
• número de colunas: onecolumn (uma coluna) ou twocolumn (duas colunas)
• impressão: oneside (imprime em apenas um lado da página) ou twoside (impressão nos dois lados do papel)
• página de título (capa): titlepage (tem capa), notitlepage (não tem capa)
• primeira página de cada caítulo: openright (forçar o documento a começar cada capítulo numa página do lado direito), openany (começa cada novo capítulo em qualquer página, sem se preocupar se está do lado direito ou não)

Na linha seguinte temos um “usepackage” que está carregando um pacote de definições, neste caso carrega o suporte a português.

Logo em seguida, pulando a linha de comentário, temos uma linha com o comando:

\begin{document}

isto indica que aqui começa o documento em si e tudo o que estiver entre \begin{document} e \end{document} é o documento em si.

Pronto, já comentamos o documento, mas falta uma coisa muito importante: e agora? Como compilar e gera um pdf? Afinal de contas, é para isso que estamos aqui, não é?

Se estiveres usando o windows, instala o MiKTeX e depois um editor, sendo que eu recomendo o teXniCenter. No menu (ou na barra de ferramentas também) encontrarás a opção build, que compilará o documento. Logo após basta abrir o mesmo e verás que tens um documento prontinho.

Se estiveres usando o linux, instale o tex pelo gerenciador de pacotes do mesmo ou compile-o pelo código fonte e use um editor (pode ser de texto ou próprio para Latex). No terminal digite:

latex filename.tex
dvipdf filename.dvi filename.pdf

ou

pdflatex filename.tex

Por hoje é só. Se aparecer alguma dúvida poste um comentário e responderei o mais rápido possível.

Tags: introdução, Latex

Há muita coisa importante a se preocupar durante a modelagem de um banco de dados, contudo achei importante mostrar algumas delas. Sei que algumas pessoas não concordarão de imediato com todas as regras, mas ainda não vi muitos argumentos válidos contra as mesmas.

Regra Nº1: evite valores Nulos em campos numéricos quando nulo for equivalente ao valor zero.

Esta regra é simples, mas muitas vezes desrespeitada, infelizmente. Via de regra, permitir NULL em um banco de dados é sinal de perigo, na medida do possível NÃO USE CAMPOS QUE PERMITAM NULOS.

Um exemplo de mal uso de nulo: imagine que tens um campo DESCONTO em uma tabela. Quando não há desconto, no lugar de marcar o campo NULL, use o valor zero.

Agora uma dica importante: nem sempre podes tirar o NULL. Um exemplo que me deram há algum tempo é quando temos um banco de dados de informações médicas onde há um campo TAMANHO_DO_TUMOR. Se nesse campo tivermos o valor zero, isso indicaria que não existe tumor algum, contudo NULL indicaria desconhecido, assim NULL não teria o mesmo significado que zero.

Regra Nº2: Evite apagar registros, sempre que possível marque-os como INATIVOS no lugar de apagá-los.

Esta regra tem duas razões de ser: a primeira é que isso facilitaria, em uma necessidade, reativar o mesmo registro, a outra, mais importante de que a primeira, é que dessa forma podemos fazer uma auditoria dos valores auterados e/ou apagados.

Regra Nº3: procure adicionar na maior parte de suas tabelas, se não em todas, os seguintes campos: DATAHORA_CRIACAO, USUARIO_CRIACAO, DATAHORA_ATUALIZACAO, USUARIO_ATUALIZACAO.

Isto facilita muito uma auditoria futura nos dados.

Regra Nº4: Crie sempre uma chave primária.

Esta é uma das regras que mais vejo sendo desrespeitadas, infelizmente. E não falo de casos específicos, que fogem às regras tradicionais de modelagem, mas sim em sistemas tradicionais. Cave primária nada mais é de que um identificador único para cada linha da tabela, o que é muito importante.

Regra Nº5: Prefira chaves primárias que tenham significado a chaves artificiais.

Já conheci muita gente que discorda desta regra e ainda não há um acordo absoluto quanto a isto, mas chaves primárias deveriam ter um significado. Por qual razão? Porque isso diminui o engano de modelar uma tabela que possa repetir valores semelhantes, visto a chave primária ser artificial e sem significado, se o restante (que é o que tem significado e o que importa realmente na base) for repetido temos falha na modelagem. Além disso, evitamos criar campos sem significado na base (uma chave autoincremental, por exemplo, seja usando sequence (em bancos que suportam isso como o postgreSQL) ou não).

Regra Nº6: Evite visões (views) redundantes.

Não crie visões do tipo

vw_funcionarios AS SELECT * FROM funcionarios

.

Regra Nº7: Tente retornar um valor de status de execução de uma função no banco de dados, ou seja, retornar zero para execução sem problemas ou o código do erro. Isso facilita verificar possíveis problemas no banco e/ou na aplicação que está chamando essa função.

Regra Nº8: Padronize os retornos de erros de funções no banco de dados.
Retorne sempre o mesmo código para o mesmo erro, mesmo que o mesmo ocorra em duas funções completamente distintas.

Regra Nº9: Siga o padrão adotado na empresa para os objetos dentro do banco de dados, mesmo que não goste dos mesmos.

Regra Nº10: Não fique no meio termo: ou a regra de negócios fica no banco de dados ou na aplicação, NUNCA parte em um parte no outro.

Paremos por aqui, cansei de escrever por hoje. Espero que sejam boas estas regras para vocês.
Abraços a todos!

Tags: database