Aqui explico como organizar diversos bancos de dados PostgreSQL utilizando o conceito de Schemas. A idéia é centralizar varias bases de sistemas distintos em um único banco, centralizando todo o seu gerenciamento. Neste processo iremos:

• Criar um novo banco de dados destinado a ser o “Banco de Dados Central”;
• Criar tablespaces para tabelas e índices e fazer com que todos os índices e tabelas de todos os sistemas armazenem seus dados nas suas respectivas tablespaces;
• Centralizar toda a codificação de caracteres para todos os sistemas em UTF8;
• Utilizar apenas um usuário administrador, o postgres para todos os sistemas;
• Utilizar um usuário e um schema com o mesmo nome para cada sistema a ser utilizado pelo desenvolvedor para criar os objetos do sistema;
• Utilizar um ou mais usuários para a aplicação com permissões restritas em cada objeto a ser utilizado;

Para isto, utilizaremos o PostgreSQL 8.1 rodando em Linux. No entanto, a maioria das coisas aqui descritas se aplicam a outros sistemas operacionais no padrão POSIX (linux, BSDs, Solaris, etc) e versões 8.x do PostgreSQL.

Parte I - Preparação

1. Criar tablespaces:

Antes mesmo de criar nosso banco de dados centralizado, criaremos os tablespaces a serem utilizados. Mesmo que você não possua vários discos ou arrays distintos para armazenar os seus dados, é importante já começar a preparar os seus sistemas para isto. Conforme eles crescem você deverá precisar de mais storage. Separar os logs, tabelas e índices e unidades físicas distintas costuma ser a providência número um para aumentar a performance. É claro que sistemas maiores podem utilizar tablespaces separados para cada sistema ou para tabelas e índices com dados históricos (utilizando o particionamento de tabelas) para aumentar ainda mais o desempenho. Como nosso tópico principal aqui não é o tunning, não nos aprofundaremos no assunto aqui.

Criaremos as seguintes tablespaces básicas:
- Uma tablespace para tabelas chamada tbs_tables
- Uma tablespace para índices chamada tbs_indexes

Antes de criar sua tablespace, você deve entender que o PostgreSQL 8.x trata cada tablespace como um diretório no seu sistema de arquivos. Portanto é preciso criar os diretórios no seu sistema operacional antes de criar os tablespaces. Também é preciso garantir a permissão de leitura e gravação nas pastas recém criadas. O local onde você irá criar seus tablespaces depende da forma como você deseja organizar sua estrutura de diretórios. Aqui, criaremos uma pasta específica para isso, na raiz. Na sua linha de comando digite:

$ su postgres
$ cd /
$ mkdir postgresql
$ cd postgresql
$ mkdir tablespaces
$ cd tablespaces
$ mkdir tables
$ mkdir indexes

Feito isto, você pode se conectar ao psql e criar os tablespaces:

$ psql

 CREATE TABLESPACE tbs_tables OWNER postgres LOCATION '/postgresql/tablespaces/tables';
 CREATE TABLESPACE tbs_indexes OWNER postgres LOCATION '/postgresql/tablespaces/indexes';

2. Criar o banco de dados central:

Feito isto, criaremos o banco de dados que servirá para para centralizar todos os seus bancos de dados. Para isto utilizarei a opção ‘-D‘ para definir um tablespace padrão a ser utilizado em todos os objetos que não especificarem um tablespace padrão. Outra opção importante é o ‘-E‘ onde especifico o tipo de codificação de caracteres.

$ createdb -D tbs_tables -E utf-8 nome_do_banco

3. Criar role padrão para desenvolvedores:

O próximo passo é criar um role que será utilizado por todos os usuários que poderão criar objetos no banco. Note que este role não será utilizado para se logar no banco e sim para que novos usuários herdem suas permissões. Concederemos permissão para:
- Criar objetos no banco de dados recém criado;
- Criar objetos nos tablespaces tbs_tables e tbs_indexes.

 CREATE ROLE developer WITH NOLOGIN;
 GRANT CREATE ON DATABASE nome_do_banco TO developer;
 GRANT CREATE ON TABLESPACE tbs_tables TO developer;
 GRANT CREATE ON TABLESPACE tbs_indexes TO developer;

Parte II - Unificando os bancos de dados

4. Fazer DUMP do banco de dados a ser migrado

A primeira coisa que você deve fazer agora é exportar cada banco de dados individual. A melhor forma de fazer isto é utilizando o pg_dump através da linha de comando. Você pode fazer alguns testes iniciais sem carregar a estrutura dos dados para ver se está tudo ok. Para isto, utilize a opção ‘-s‘. Depois você pode exportar apenas os dados utilizando a opção ‘-a‘.

$ pg_dump --use-set-session-authorization -E utf-8 -h ip_do_banco -U postgres nome_do_banco_a_ser_migrado > nome_do_banco_a_ser_migrado.sql

a opção ‘–use-set-session-authorization’ é opcional. Ela faz com que seja utilizada o comando SQL ‘SET SESSION AUTHORIZATION‘ ao invés do ‘ALTER … OWNER‘ para cada objeto. A opção ‘-E‘ força a exportação ser realizada na codificação de caracteres desejada. Desta forma não é preciso utilizar o iconv ou mudar o ‘client enconding‘ para importar os dados na codificação correta.

5. Editar o dump:

Agora vem a parte mais importante do processo de migração, editar o dump e corrigir algumas coisas:

• Alterar o tablespace para as tabelas e índices com o comando SQL ‘SET default tablespace‘;

• Criar o usuário que será dono do schema e todos os objetos dentro dele, a ser utilizado pelo desenvolvedor. Colocamos também um limite de conexões para este usuário para impedir que o desenvolvedor tente utilizar este usuário como usuário da aplicação;

• Criar um ou mais usuários a serem utilizados pela aplicação;

• Criar o schema e defini-lo como padrão para que todos os objetos subsequentes sejam criados dentro dele, através da instrução ‘SET search path‘;

• Criar as permissões para os usuários das aplicações concedendo apenas os privilégios realmente necessários para eles.

Alguns cuidados:

• Utilize um editor em modo texto, principalmente se o seu dump for muito grande. Isto irá facilitar o seu trabalho de edição, pois abrir arquivos grandes em modo gráfico pode acabar com a memória do seu computador mais rápido do que em modo texto. Outra alternativa é criar um dump separado para a definição de dados DDL e outro para os dados em DML. A maior parte das alterações dizem respeito apenas a DDL, que são arquivos bem menores.

• Verifique se existe uma linha igual a esta no início do arquivo:
  SET client_encoding = ‘utf-8′;
  ela é importante para garantir que o psql vá utilizar a codificação correta durante a importação. Caso você esteja utilizando outra codificação, você poderá ter problemas durante a importação. Mude a codificação de caractere para UTF8 ou mude o ‘client-encoding‘ para aquele que o arquivo do dump está utilizando.

• Algumas linhas como o ‘SET default tablespace‘ e ‘SET search path‘ já vem no dump padrão realizado pelo pg_dump. Ao invés de reescrever estas linhas, apenas altere a já existente. O risco não fazê-lo é criar um parâmetro que será sobrescrito pré-existente no dump pouco após da linha que você acrescentou.

• Algumas funções em PL são criadas dependendo da versão do PostgreSQL que você está utilizando. Estas funções costumam ser criadas ao se criar o banco de dados ou ao se implementar alguma funcionalidade do diretório contrib do PostgreSQL. Geralmente, estas funções são comuns a todos os sistemas e não precisam ser incluídas novamente. Costuma ser seguro remover estas linhas do dump. Caso ocorra algum problema durante a homologação, você poderá criar um novo dump e recuperar as funções da base de dados antiga.

5.1 Criando usuários:

CREATE ROLE sistema_a WITH LOGIN PASSWORD '123456' INHERIT IN ROLE developer CONNECTION LIMIT 2;
CREATE ROLE sistema_a_client WITH LOGIN PASSWORD '123456';
SET SESSION AUTHORIZATION sistema_a;

Note aqui que o ‘INHERIT IN ROLE developer‘ faz com que o usuário faça parte da role developer e ainda herde as permissões dele. A linha ‘SET SESSION AUTHORIZAION‘ faz com que os objetos subsequentes sejam todos criados com o usuário citado como owner.

5.2 Criando o schema:

Agora criaremos o schema com o mesmo nome do usuário do desenvolvedor. É importante que o usuário tenha o mesmo nome do schema, pois no arquivo postgresql.conf o ’search_path’ inclui a variável ‘$user‘ por default. Isto significa que o nome do usuário que se conectar procurará automaticamente objetos neste schema sem precisar qualificar seu nome ou utilizar o ‘SET search path‘.

CREATE SCHEMA sistama_a AUTHORIZATION sistema_a;

5.3 Definido os tablespaces

Para definir o tablespace, você deve procurar dois pontos importantes no seu dump: o ponto imediatamente anterior antes de criar as tabelas e o ponto imediatamente anterior a criação dos índices e constraints.

Antes da criação das tabelas coloque a seguinte linha:

SET default_tablespace = 'tbs_tables';

Antes da criação de índices e constraints, coloque a seguinte linha:

SET default_tablespace = 'tbs_indexes';

5.4 Concedendo privilégios aos usuários da aplicação

No final do dump, o pg_dump coloca as permissões inerentes aos objetos criados para cada usuário. Esta parte do trabalho não tem como ser automatizada. É interessante manter o REVOKE para o usuário PUBLIC de forma a zerar as permissões para todos os usuários antes de concedê-las novamente. Evite a todo o custo conceder privilégios do tipo ALL, a fim de não conceder mais privilégio do que o estritamente necessário para cada usuário. Apesar de ser uma tarefa tediosa, esta é uma tarefa importante no trabalho de qualquer bom DBA. Privilégios do tipo CREATE, TEMP, DELETE, RULE, REFERENCES, TRIGGER que só devem existir em usuários de sistema em casos específicos.

6. Importação

O último passo é importar cada dump devidamente alterado no passo anterior para o banco de dados central.

$ psql -h ip_do_banco -U postgres nome_do_banco < nome_do_banco_a_ser_migrado.sql

7. Testes

Por fim, deve-se testar a aplicação para que ver se tudo está funcionando adequadamente com o usuário do sistema e senha nova. Pode ser necessário qualificar o nome dos esquemas para acessar os objetos no local correto. Uma alternativa mais simples é utilizar a instrução ‘SET search path‘ logo após a conexão com o banco de dados. Uma boa idéia é utilizar também a instrução ‘SET client enconding‘ utilizando a codificação da sua aplicação. Como o UTF8 tem a capacidade de ser convertido para a maior parte dos tipos de codificação, ele é ideal para ser utilizado no servidor, enquanto no cliente você pode escolher o tipo de codificação mais adequado para a sua aplicação.

Lembre-se de testar cuidadosamente sua aplicação antes de libera-la para a produção. Um servidor de testes é fundamental para este processo.

Referências:

• Schemas: http://www.postgresql.org/docs/8.1/interactive/ddl-schemas.html
• psql: http://www.postgresql.org/docs/8.1/interactive/app-psql.html
• pg_dump: http://www.postgresql.org/docs/8.1/interactive/app-pgdump.html
• CREATE DATABASE: http://www.postgresql.org/docs/8.1/interactive/sql-createdatabase.html
• CREATE TABLESPACE: http://www.postgresql.org/docs/8.1/interactive/sql-createtablespace.html
• CREATE SCHEMA: http://www.postgresql.org/docs/8.1/interactive/sql-createschema.html
• CREATE ROLE: http://www.postgresql.org/docs/8.1/interactive/sql-createrole.html
• GRANT: http://www.postgresql.org/docs/8.1/interactive/sql-grant.html
• REVOKE: http://www.postgresql.org/docs/8.1/interactive/sql-revoke.html
• SET: http://www.postgresql.org/docs/8.1/interactive/sql-set.html
• SET AUTHORIZATION SESSION: http://www.postgresql.org/docs/8.1/interactive/sql-set-session-authorization.html

Aconteceu! O “III Fórum Regional de Software Livre do ABCD” foi um sucesso!

Acho que este Fórum marcou o PSL-ABCD com um toque de profissionalismo e descontração ao mesmo tempo. Tínhamos os elementos centrais de um evento de grande porte:

• Stands com patrocinadores,
• Acesso a Internet com wireless,
• Um espaço amplo e bem arrumado,
• Sala VIP para a organização e palestrantes,
• Site, banner, faixa, crachá, camisetas, brindes, etc,
• Palestrantes de alto nível,
• Abertura com representantes do governo, iniciativa privada e sociedade civil organizada,
• Caravanas vindas de Santo André e de São Roque,
• Doação de alimentos

Além disso, temos a irreverência de um evento regional, com cervejas no Bar do Zé, Show Creative Commons, Palestras animadas com a platéia e até sorteido de autógrafo do fike!

Acho que o evento foi muito bom mesmo. Acho que contamos com a ajuda de muita gente do PSL-ABCD durante o evento. Conseguimos fazer tudo sem dependência financeira dos organizadores. Todo o evento foi bancado com a verba dos patrocinadores, o que confere maior autonomia para o PSL-ABCD. Contamos, é claro com muita ajuda da Prefeitura de Diadema e do Centro Público Valdemar Mattei, mas creio que saímos mais maduros no processo.

Ainda temos muito o que melhorar. Precisamos realizar eventos em outras cidades do ABCD, conquistar novos espaços, especialmente nas universidades. Ainda temos poucas pessoas envolvidas diretamente na organização de todo o evento. Precisamos de mais gente participando. Ainda contamos com boa parte das mesmas pessoas organizando o I, II e III fórum. Por outro lado, temos novas pessoas colaborando, como o Alexandre Rossi Paschoal, a Tatiana Cunha e o Erick Müller.

Como de costume, estamos recebendo novas pessoas na lista do PSL-ABCD, espero que com este novo gás, consigamos crescer mais ainda e concretizar ações cada vez mais efetivas em prol do Software Livre e sua comunidade.

Ainda temos muita coisa para fazer este ano, aparar algumas arestas do III Fórum e começar a preparar as últimas oficinas do ano. Embora cansado, eu me sinto muito satisfeito em ver o trabalho de uma equipe que trabalhou muito concretizado num excelente evento.

Parabéns para todos, parabéns para nós, pizza, café, cerveja e Software Livre para todos!

Estará sendo realizada também a inscrição para as provas 101 e 102 da LPI no local do evento.
Uma novidade que ocorrerá no Fórum, será a “GPG Key Signing Party” organizada pelo Fernando Ike, no dia 23/09 às 12h. Os interessados em trocar suas chaves criptográficas GPG e ainda não possuírem são convidados a ler nota com links para tutoriais e demais explicações sobre o assunto no site do PSL-ABCD.

Esperamos poder rever amigos e conhecer muita gente nova por lá. Até mais.

Tudo pronto para o grande dia, o “III Fórum Regional de Software Livre do ABCD” começa amanhã. Com mais de 650 inscrições, até agora, este ano o evento realmente promete!

Mas para chegar até aí…

• Quase 1000 cartazes espalhados na Grande São Paulo, Santos e até em RJ!
• 1 faixa colocada em frente ao Teatro Clara Nunes
• 1 banner já está pronto, para ser colocado no palco
• Decoração da mesa e flores já estão contratados
• Mesas para os patrocinadores reservadas
• 2 caixas de água para os palestrantes já foi conseguido
• 1 projetor Multimídia reservado
• 500 crachás já estão prontos
• 600m de cordão para os crachás já foram comprados
• 500 Etiquetas para os crachás foram compradas
• 100 Etiquetas especiais para organização, palestrantes e patrocinadores foram feitas
• 20 pinceis atômicos para colocar o nome no crachá foram comprados
• Confirmação da grade das palestras foi feito.
• 200 Fichas de inscrição para quem não se inscreveu pelo site foram impressas
• Restaurante para o almoço no sábado foi reservado
• Conexão com Internet sem fio providênciada
• 7 oradores na abertura confirmados
• 5 palestrantes convidados confirmados
• 11 propostas de palestras da comunidade
• 5 palestrantes da comunidade escolhidos e confirmados
• Cerimonial para abertura organizado
• 250 Certificados impressos
• 300 camisetas estão prontas
• 3 bandas confirmadas para o show de encerramento
• 15 cadeiras universitárias para aplicação das provas da LPI reservadas
• 11 patrocinadores com R$ 2.830 arrecadado
• 4 apoiadores
• 3 entidades organizadoras

Fala sério, se para fazer um evento regional já dá todo este trabalho, imagine um evento como o FISL e o CONISLI! E até o final do evento ainda tem muito chão pela frente!

Uma excelente oportunidade para aprender mais sobre software livre e de quebra colaborar com a comunidade:

No site http://torrents.softwarelivre.org você vai encontrar vídeos das palestras do FISL 6.0 e 7.0 no formato torrent. Além de assistir o que há de melhor em palestras realizadas no Brasil nos últimos 2 anos, você pode contribuir com as demais pessoas que também querem assistir às palestras, semeando as palestras que você baixar.

Já assisti algumas palestras e já estou baixando várias outras. O FISL 7.0 foi particularmente interessante para o PostgreSQL que dominou o segmento de Banco de Dados. No entanto já estou baixando palestras sobre MySQL e Firebird também!

Recomendo algumas que eu já assisti como a do Sr. David Fetter sobre o DBI-Link, que é mais um extrangeiro que se apaixonou pela caipirinha e estará de volta no CONISLI ainda este ano. Outra muito legal foi a do Diogo de Oliveira Biazus, que falou sobre otimização do PostgreSQL.

Tive a infelicidade de baixar a minha própria palestra e ver que ainda preciso melhorar muito nas minhas apresentações. Serviu de lição. De toda forma, ver a si mesmo na tela é sempre muito estranho!

Em todo caso, tem outras coisas muito interessantes para se ver, nos mais variados temas. Então, quem não foi, ou mesmo quem foi e não conseguiu ver tudo o que queria, aqui está uma oportunidade imperdível.

Um detalhe importante: todas as palestras estão licenciadas sob a Creative Commons. Portanto: não deixe de semear seus torrents!

“Começa neste dia 21 de setembro na quinta-feira às 19h o ‘III Fórum Regional de Software Livre do ABCD’. O evento será realizado em Diadema, Grande São Paulo, no Teatro Clara Nunes. Até o dia 21, será possível se inscrever com desconto especial para o evento nas provas da LPI 101 e 102 a serem realizadas no dia 23 durante o evento. Os preços serão reajustados na próxima semana, portanto é a última chance para conseguir um preço especial. Os interessados devem entrar no site da LPI Brasil ou entrar em contato pelo telefone 2125-4747. Já temos atualmente mais de 560 inscritos no fórum. A expectativa é de chegar em mais de 800 inscritos. Se você ainda não se inscreveu, entre agora mesmo no site do evento . ”

Últimos preparativos para a realização do fórum. Há 3 dias da realização, há muito o que fazer ainda.

Esta semana deve começar bem agitada. Neste último sábado o fike esteve com as bandas no Teatro para ver os últimos detalhes do show. Hoje, 18/09 devo ter reunião com autoridades da Prefeitura de Diadema para contextualizar sobre a realização do Fórum. Vou aproveitar e dar uma pulo na comunicação que deve conseguir um artigo em jornal para nós. Ainda passo no cerimonial para acertar parte da cerimônia de abertura. Teremos o Alexandre Rossi Paschoal representando o PSL-ABCD e o André da Tempo Real apresentando os empresários. Além deles, teremos autoridades de prefeituras do ABCD subindo à mesa também.

Depois tenho que pegar os certificados e providenciar as cópias das fichas de inscrição.

Ainda na segunda temos que conferir mais uma vez toda a contabilidade do fórum e conferir os depósitos dos últimos 2 patrocinadores. Depois mando todos os dados para serem feitos os recibos.

Até a terça feira, tenho que comprar os cordões dos crachás, pegar os crachás e banner e pagar a faixa em frente o teatro.

Na quarta tenho que checar se as camisetas chegaram, realizar as últimas compras.

Hoje, eu estava lendo um artigo do BR-Linux comentando que o criador do PHP recomendou o uso do MySQL ao invés do PostgreSQL para aumentar a velocidade das aplicações. Isto me lembrou de outro artigo postado do BR-Linux onde o autor compara o desempenho de diversas linguagens de programação.
Como fui adolescente há não muito tempo, ainda me lembro das intermináveis discussões sobre as qualidades do MSX e Apple II.

<!– @page { margin: 2cm } P { margin-bottom: 0.21cm } –>

O Software Livre traz consigo uma liberdade que para muitos é difícil de desfrutar. Bem, mas antes de mais nada eu gostaria de lembrar de algo mais agradável, que tem haver com a maioria dos bons programadores: o café e a cerveja!

Ambos possuíam fabricação caseira ou semi-industrial até alguns séculos atrás. Um bom café era chato de ser preparado e a cerveja depois de pouco tempo de fabricação azedava. Com o advento da pasteurização, surgiram as grandes cervejarias e com o advento do café solúvel, qualquer criança prepara um café em segundos. O problema disso é que a qualidade do café e da cerveja caiu drasticamente. Para atender a um processo de fabricação em larga escala, algumas coisas se perderam no caminho. Mais que isso, o processo de comercialização em larga escala exige que se tenha um produto com boa aceitação pela maioria dos consumidores. Assim, foram consagradas fórmulas medias capazes de satisfazer a maioria dos paladares em todo o mudo. Há poucas décadas, a liberdade de escolha está ressurgindo. Pequenas cafeterias e cervejarias estão ressurgindo, oferecendo diferentes tipos de café e cerveja de fabricação artesanal. Isto não significa que passaremos a consumir produtos artesanais ao invés de industrializados. Significa que existem sabores diferentes dos que estamos acostumados. Alguns podem ser muito interessantes, outros não. Alguns caem bem com determinados tipos de comida, ou combinam com um clima em particular. A indústria continuará oferecendo bom café e cerveja para a maioria das ocasiões. Haverá no entanto momentos em que outras opções podem ser mais interessantes. Certamente não se pretende que um substitua o outro.

Dizer que a linguagem A é melhor que B, ou comparar editores e SGDBs tem o mesmo efeito. Mesmo a solução de maior sucesso pode ser menos apropriada do que outra melhor adaptada para situações específicas. Já dei algumas palestras de PostgreSQL por aí e sempre mantive um excelente relacionamento com palestrantes sobre MySQL.

Sou obrigado a reconhecer que uso ambos. Aliás, eu diria que há projetos em que o SQLite é uma excelente opção. Em outros sou obrigado a dizer que ainda precisamos de algo do porte de um Oracle.

O mais importante afinal é que você possa escolher a cerveja que mais lhe agrade e se sentir satisfeito com ela. Se der sorte, pode descobrir outras muito interessantes que podem lhe apetecer em alguns momentos. No final, refinando seu paladar você só tem a ganhar.

“Álcool: A causa de, e a solução para, todos os problemas da vida.” —Homer Simpson

Há tempos que eu vejo meus feeds no Xoops de forma ruim. Hoje resolvi arregaçar as mangas e acertar as coisas aqui.

Primeiro eu instalei um módulo novo no Xoops que parece bem legal. O Planet faz exatamente o que ele promete. Coloquei alguns blogs de amigos para testar e achei bem legal. Ainda não testei os blocos dele, mas já me considero satisfeito por poder montar um planeta em um par de minutos.

Depois fui arrumar o rss que não aparece a esquerda do url do meu site. Percebi que o tema que escolhi no Xoops não tinha uma linha. Foi só colocar no cabeçalho e pimba!

Por fim, algo que sempre me pentelhou foi não poder ler as postagens do blog completos. Arrumei isso mexendo no arquivo backend.php e concatenando a variável $bodytext que contém o restante do post ao cabeçalho da notícia.

Acho que agora está ficando mais bacana! Só falta mesmo acrescentar o link para o rss no rodapé. Mas ainda não sei direito como arrumar isso de forma mais ou menos estética. Como programador, costumo ter muita dificuldade nesta parte do design. Então vou deixar isso para depois.

Estes dias recebi um e-mail onde a pessoa me pergunta qual seria um bom caminho a seguir para quem está começando a mexer com PostgreSQL. Como vejo muitas pessoas novas utilizando o PostgreSQL, deixo aqui as minhas observações que podem ser petulantes ou óbvias para muitos, mas julgo ser de interesse de quem está realmente começando.

No final, deixo alguns links interessantes.

1. Aprenda inglês! Mais importante que fazer faculdade ou um curso de informática é aprender inglês. Se você pretende fazer algum investimento a curso prazo e não sabe ler bem em inglês, este é um ponto de partida obrigatório. Os melhores profissionais de informática são aqueles que tem a capacidade de aprender sozinhos. E quando você começar a estudar por conta própria, vai descobri duas coisas:
   • A Internet é o meio mais barato, rápido e rico para achar material para se atualizar e para descobrir coisas novas.
   • Os melhores artigos, sites de notícias, blogs, livros, revistas, listas de discussão, canais de IRC, etc estão todos em inglês. Uma porcentagem muito pequena deste material é traduzida para o português e quando isto acontece costuma estar sempre um pouco desatualizado. Isto não significa que não existem excelentes materiais em português. Significa que a maioria dos profissionais de TI no mundo todo se comunicam através do idioma inglês.
2. O mais importante de tudo é achar um desafio real e tentar encontrar uma solução real. Quando eu comecei a aprender, meu primeiro banco de dados era sobre a minha coleção de Discos e vinil. Depois montei um banco de dados para uma loja de discos e por aí fui. Encontrar soluções para um problema real faz você encontrar problemas reais e desafia você a pesquisar soluções.
3. LEIA a documentação do banco de dados que você vai utilizar. Faça alguns exercícios para testar, mesmo se forem coisas aparentemente simples. No começo, a interface e a sintaxe de cada SGDB sempre confunde os novatos. No site do PostgreSQL existe uma excelente documentação, melhor que a maioria dos livros sobre SGDBs proprietários que você pode encontrar em livrarias por aí. Leia pelo menos as partes I, II e alguns capítulos da parte III.
4. Evite usar interfaces com bancos de dados que facilitem muito o trabalho por você. Se você realmente quer aprender, use primeiro interfaces no modo texto. Existem excelentes razões para isto:
   • No modo texto você sempre sabe o que está acontecendo.
   • No modo texto você é obrigado a aprender a sintaxe correta dos comandos
   • Pessoas que aprendem a trabalhar no modo texto aprendem rapidamente a trabalhar no modo gráfico. O contrário nem sempre é verdade.
   • Ao executar rotinas pesadas, o modo texto é sempre mais confiável e apresenta melhor desempenho.
   • Interfaces no modo texto dificilmente apresentam bugs e dificilmente travam. Algumas vezes uma operação complexa apresenta erro devido a uma falha na interface gráfica e não sua.
   • Na interface em modo texto todas as operações avançadas do banco de dados estão disponíveis. No modo gráfico isto nem sempre ocorre.
   • Para usuários mais experientes o modo texto costuma ser mais produtivo.
   • Se um dia você precisar operar um servidor em produção em ambiente crítico, ele provavelmente (se for um servidor bem configurado) não terá uma interface gráfica instalada. Se um dia você precisar operar o servidor localmente, você precisará usar a interface em modo texto. Isto ocorre geralmente em momentos críticos onde o tempo que você demorar para resolver o problema pode custar o emprego de toda uma equipe.
5. Participe da comunidade de Software Livre. A comunidade é um excelente local para conhecer muita gente interessante, receber ajuda e ajudar outras pessoas. Você conhecerá pessoas muito que lhe ajudarão muito. Em breve você será capaz de ajudar um pouco outras pessoas também. Com uma pequena quota de ajuda, você será recompensado com incontáveis contribuições de todo o planeta. Você pode participar de listas de discussão por e-mail, canais de IRC, fóruns web e eventos presenciais. As listas de discussão costumam ser um ponto de partida obrigatório. Existe no entanto algumas dicas essenciais para que entra em uma, que são sempre citadas, mas muitas vezes ignoradas:
   • Leia o manual primeiro!
   • Escreva corretamente utilizando boa gramática. Não use gírias e evite abreviações.
   • Procure no histórico da lista para ver se a sua dúvida já não foi respondida antes. Os novatos costumam sempre ter o mesmo tipo de dúvida que acabam sendo respondidas várias vezes. Responder centenas de vezes a mesma pergunta é desestimulante mesmo para os mais altruístas.
   • Nunca utilize como assunto de um e-mail coisas como “preciso de ajuda” ou “não funciona”. Muitas listas têm um tráfego diário de dezenas de e-mails por dia. Logo se torna impossível de ler todas as mensagens recebidas. As pessoas selecionam o que vão ler pelo assunto da mensagem. Procure colocar um assunto curto e que dê idéia sobre qual o tipo de problema que você tem.
   • NUNCA mande spam ou mensagens cujo conteúdo não seja diretamente relacionado com a lista em questão. Você poderá ser banido da lista, ou no mínimo será mau visto pelos demais participantes.
   • Não entre em discussões acaloradas (flame wars) que não levam a lugar nenhum. Estas discussões dificilmente contribuem para o todo. Se tiver uma crítica que julgar indispensável, faça-a de forma polida, respeitosa e de preferência não envie para a lista e sim direto para o destinatário.
   • O Google e outros sites rastreiam boa parte do conteúdo das listas de discussão que são públicas. Isto significa que tudo o que você escrever ficará publicado para o mundo inteiro por muitos anos. Pense nisso antes de escrever. Muitas oportunidades são perdidas por assumirmos posições radicais em um determinado momento da vida, ou por não demonstrar maturidade profissional. A primeira coisa que qualquer pessoa faz antes de contratar alguém na área de TI é colocar o nome da pessoa no Google e ver o que acontece.
6. Procure saber o que você sabe e saber o que você não sabe. Isto significa, conhecer os seus limites, ser humilde e ter bom senso. Saiba quais são seus limites pessoais. Procure se informar em várias fontes de informação antes de emitir uma opinião, nunca de respostas fáceis ou aceite desafios sem saber exatamente o risco que você está assumindo. No começo é comum se empolgar no momento em que você começa a ter familiaridade com um SGDB e se sentir mais a vontade. No entanto, um ambiente de teste e um ambiente de produção costumam ter diferenças que às vezes dependem de anos de experiência para se aprender como tuning, segurança, fail over, replicação, etc. Isto não significa que você não deve se lançar a novos desafios, significa que é sempre bom poder contar com uma boa retaguarda antes de explorar o desconhecido. Mesmo que isto implique a diminuir algumas vantagens circunstanciais.
7. Valorize o conhecimento e as pessoas e não o dinheiro. Ninguém que está começando ganha dinheiro imediatamente. O mercado de trabalho está repleto de profissionais de informática com baixa qualificação. No início de carreira prefira oportunidades de emprego que lhe dêem possibilidade de aprender mais à um bom salário.
8. Procure entender o que você faz ao invés de aceitar receitas prontas. Um how-to ou um tutorial, podem ser um bom ponto de partida para se começar a ter contato com uma nova tecnologia. Mas se seu trabalho realmente depender dela, você terá que se aprofundar nela e entender como ela realmente funciona. Tutoriais curtos que ensinam as coisas passo-a-passo só funcionam para ambientes ideais em circunstâncias específicas. Quando as coisas dão errado, este tipo de documentação pouco ajuda.
9. Uma tradição entre os profissionais de TI, que é importante ter em mente, é que os DBAs costumam ser as pessoas mais conservadoras da equipe. Eles dificilmente confiam em coisas novas. São sempre os últimos a quererem migrar qualquer coisa ou dar ouvidos aos modismos de mercado. Isto ocorre por um motivo muito simples, o maior patrimônio de TI costuma ficar sob sua responsabilidade: os dados! Qualquer possibilidade de um problema degenerar os dados de forma lenta e imperceptível leva toda uma empresa a uma situação catastrófica e irreversível. Existem empresas que chegam a fechar as portas por causa destas coisas. Funcionários e máquinas são substituíveis em TI. Os dados históricos acumulados por anos em uma empresa não. Outra coisa que reforça posições conservadoras é que apesar de existirem inúmeros softwares sendo lançados a cada dia, os SGBDs costumam ter um ciclo de desenvolvimento muito longo e a maior parte da teoria de bancos de dados relacional ainda é a mesma enunciada na década de 70.
10. Conheça a diferença entre os diferentes SGDBs existentes no mercado. O PostgreSQL é uma excelente solução, mas em alguns casos específicos, outros bancos de dados podem apresentar algumas vantagens. Entre os SGDBs livres, se destacam, além do PostgreSQL, o MySQL, o Firebird, o SQLite. Entre os proprietários, os SGDBs mais expressivos são o Oracle, o IBM DB/2 e o MS SQL Server. Há também uma nova e polêmica geração de bancos de dados orientados a objeto que pretendem substituir os bancos de dados relacionais em situações específicas. Em todo caso, independente do SGDB com o qual você pretende iniciar seus estudos ou se especializar, é sempre importante manter a mente aberta e saber que cada solução possui vantagens e desvantagens. O estado de arte é saber quando vale pena utilizar outro SGDB.

Alguns links interessantes para quem quer começar a Mexer com PostgreSQL:

0 - http://en.wikipedia.org/wiki/Data_base_management_system
Artigo no Wikipedia sobre SGDBs.

1 - http://www.postgresql.org
Site oficial do PostgreSQL

2 - http://www.postgresql.org.br
Site oficial do PostgreSQL no Brasil

3 - http://pgfoundry.org
Site com projetos relacionados ao PostgreSQL com licenças livres

4 - http://planetpostgresql.org
Blogs sobre PostgreSQL em inglês

5 - http://planeta.postgresql.org.br
Blogs brasileiros sobre PostgreSQL

6 - https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Lista de discussão do PostgreSQL no Brasil

7- http://www.postgresql.org/community/lists
Listas de discussão do PostgreSQL em inglês

8 - http://www.postgresql.org/community/weeklynews
Notícias semanais sobre PostgreSQL em inglês

9 - irc://irc.freenode.net/#postgresql-br
Canal brasileiro no IRC sobre PostgreSQL

10 - irc://irc.freenode.net/#postgresql
Canal oficial no IRC sobre PostgreSQL em inglês

11 - http://www.postgresql.org/docs
Documentações oficiais do PostgreSQL em inglês

12 - http://pgdocptbr.sourceforge.net/pg80/index.htm
Tradução parcial da documentação da versão 8.0 do PostgreSQL

13 - http://www.postgresql.org/docs/techdocs
http://www.varlena.com/GeneralBits/pt.php
Artigos sobre PostgreSQL

14 - http://www.midstorm.org/~telles/?p=59
http://www.midstorm.org/~telles/?p=60
http://www.midstorm.org/~telles/?p=63
Artigo meu em 3 partes com links para diversos outros sites intitulado “Desvendando o Mundo do Software Livre”