Como deveria ser um livro sobre PostgreSQL

Já faz algum tempo que eu leio documentações de informática. Acabei aprendendo a ler em inglês pois não havia nenhum manual para o editor Magic Windows II que eu rodava no Apple II em português. De lá para cá li muita coisa que eu gostei e coisas que eu prefiro nem lembrar. Entre as coisas que eu gostei de ler está o livro Programação Perl dos Srs. Larry Wall, Tom Christiansen e Jon Orwant. É bom pois é bem abrangente, bem escrito, com boa profundidade e bom humor. A documentação oficial do PostgreSQL também é bem escrita e bem abrangente. Uma boa diferença é que como o livro de Perl não pretende ser uma documentação oficial, ele é mais descontraído. Esta é uma característica comum das documentações relacionadas com Software Livre.

Uma outra diferença fundamental é que a documentação do PostgreSQL mostra detalhadamente “o que” mas mostra pouco “como”. Isto não significa que precisamos de um livro do tipo “Torne-se um DBA PostgreSQL em 7 dias”. Estes livros costumam ter o péssimo hábito de emburrecer as pessoas com receitas de bolo prontas e não convida o leitor a pensar ou tomar decisões. Quando li a documentação oficial do PostgreSQL pela primeira vez, me senti finalmente encorajado a começar a modelar meu primeiro sistema dedicado a ele. No entanto, uma infinidade de desafios e decisões apareceram no caminho, e a documentação oficial tinha pouco a me dizer naqueles momentos. Eu ainda tinha pouca experiência e isso me levou a tomar decisões baseadas muitas vezes no meu bom senso e outras em alguns poucos artigos que encontrei na Internet. Mas… já dizia o Sr. Hobbes, que o bom senso é o dom mais democrático e contraditório da humanidade: todos acham que os outros carecem e bom senso e se julgam igualmente possuidores de boas doses dele. Resultado, fracassei miseravelmente em diversos aspectos.

Com o tempo e envolvimento com a comunidade, fui descobrindo um erro aqui e outro acolá. Aprendendo sobre outros bancos de dados, principalmente olhando para as diferenças entre eles, percebi algumas coisas nas entrelinhas que nem sempre estão explícitas na documentação. Isto me levou a escrever alguns artigos neste blog, particularmente nos últimos tempos, quando comecei a me sentir mais corajoso no sentido de expor minhas idéias e me permitir errar, expondo idéias inacabadas. Isto culminou com uma palestra no PGCon Brasil 2007. A idéia da palestra “Como Fazer um Elefante Passar Debaixo da Porta” era a de ajudar as pessoas que estão começando a utilizar o PostgreSQL, mas não tem tanta experiência como DBA. Olhando para o público do evento, percebo que existe uma minoria de DBAs na platéia. A maioria eram desenvolvedores/analistas/programadores e haviam também administradores de sistemas/redes. A questão é a de que praticamente não existem cursos de graduação para formar Administradores de Bancos de Dados. A meu ver, a maioria dos DBAs foram administradores de sistemas ou desenvolvedores que por alguma razão misteriosa decidiram se especializar nesta área.

Se formos pensar bem, o DBA fica justamente numa posição entre o desenvolvedor e o administrador de sistemas. O novo DBA trás certamente as melhores práticas da sua área de origem. Os administradores de sistema trarão uma preocupação com o uso e monitoramento dos discos, métodos de autenticação autenticação, ajustes do SO e por aí vai. O desenvolvedor trás um padrão de codificação, esquemas de autenticação da aplicação, modelagem, distribuição de objetos, etc. Mas bancos de dados não são novos… já em priscas eras, os computadores utilizam bancos de dados. O modelo relacional, no qual todos os grandes SGDBs se baseam (e ao contrário do que o pessoal da programação orientada a objeto imagina, continuará assim por um bom tempo) foi criado há mais de 30 anos. O livro “Introdução a Banco de Dados” do C. J. Date também já é pode ser considerado um clássico e está em sua oitava edição.

Os bancos de dados relacionais atravessaram a era dos sistemas centralizados em mainframes (que continuam existindo), a era cliente-servidor e a era programação em 3 camadas. O PostgreSQL tem suporte para utilizar tudo isso, mas nem sempre os novos DBAs tem consciência desta história toda. Ao ler a documentação do PostgreSQL, hoje eu vejo décadas de história relacionadas com as suas funcionalidades. Então fica claro para mim, qual livro falta ser escrito para o PostgreSQL. Não é um livro que substiua a documentação oficial. Vale muito mais a pena complementar e traduzir a documentação oficial do que escrever pequenos livros que repetem boa parte do que já existe lá. Hoje eu descobri mais um pequeno livro sobre PostgreSQL. Nada contra o livro. Mas eu não preciso ler ele para saber como ele é. Este tem apenas 240 páginas. Para um livro genérico, isso mal dá para começar. Segundo a editora, a Érica que tem fama de fazer livros didáticos, que mais parecem apostilas. Terceiro, o autor, com quem eu já tive aula, tem dezenas de livros editados no mesmo estilo.

Minha idéia não seria esta, muito pelo contrário. Acredito que um bom livro de melhores práticas deveria estimular o leitor a ler a documentação com freqüência, citando-a em diversos pontos. Mesmo porquê, existe um trabalho intenso da comunidade em atualizar a documentação oficial a cada nova versão do PostgreSQL. Um livro de melhores práticas deveria se um pouco menos dependente de uma versão específica.

Um livro de melhores práticas deveria servir como subsídio didático para cursos de PostgreSQL, deveria conter inúmeros exemplos práticos e conduzir o leitor ao erro. Sim, ao erro. Somente a pessoa que erra tem condições de aprender de fato. Não são os acertos sucessivos que nos fazem acertar, e sim os erros e como corrigi-los. Assim, eu imagino uma aplicação sendo construída a partir do seu início, e as decisões sendo tomadas no meio do caminho. Imagino o livro conduzindo a decisões e discutindo as implicações destas decisões. Imagino muita polêmica onde não há um único caminho correto a seguir. Imagino a coleta de diferentes opiniões que convidem o leitor a pensar e escolher o seu próprio caminho. Imagino exemplos concretos de como seria a implementação em cada um destes caminhos. A questão ao fim é mostrar “como” e não “o que”.

O livro passaria certamente por tópicos que não são específicos do PostgreSQL. Uma coisa interessante seria mostrar as diferenças da implementação do PostgreSQL com as implementações de outros bancos de dados, quando isso for comparável. Imagino particularmente comparações entre implementações do Oracle, DB2, SQL Server e MySQL. Imagino também comparações com o padrão SQL e comparações com versões anteriores do próprio PostgreSQL. Seria muito interessante abrir o jogo aqui. O PostgreSQL não é perfeito e nunca será. Se ele fosse perfeito a humanidade teria esgotado a sua insatisfação e imperfeição eternas. Poderia-se mostrar onde outros bancos de dados oferecem vantagens e desvantagens em relação ao PostgreSQL. Pode-se dizer o mesmo em relação ao padrão SQL, que não é perfeito. No entanto, melhor do que criticar o padrão SQL – afinal, querendo ou não é o padrão que nós temos – devemos comparar os Bancos de Dados tendo o padrão SQL como referência.

Imagino algumas premissas para escrever o livro:

• Escrito a várias mãos. É preciso de alguém para organizar o livro, mas é preciso pegar o que há de melhor na especialidade de cada um. Uns conhecem melhor modelagem de dados, outros conhecem melhor que ninguém como ajustar a performance do seu servidor ou de uma consulta. Em momentos polêmicos, poderíamos citar mais de um autor e deixar o leitor tirar suas próprias conclusões.
• Licença livre. Seria imprecindível adotar uma licença que permita a cópia e modificação do livro. Gostaria no entanto de preservar a contribuição de cada pessoa no livro. Já vi trechos da documentação do PostgreSQL em diversas apostilas por aí. Sim, daquele curso que você está pensando também. Acho que manter os créditos é uma questão de respeito. Cada um pode alterar o livro para as suas necessidades e utilizar da forma que melhor entender, mas por favor, cite os autores que lhe ajudaram.
• Precisaria ser construído aos poucos. A idéia não seria juntar um monte de texto, revisar, publicar e abandonar. Muito pelo contrário, seria feito em capítulos, sendo que qualquer capítulo poderia sofrer acréscimos e correções a qualquer momento, eternamente.
• Precisaria ser construído via Internet. Não há como um projeto colaborativo prescindir do uso da internet. Não tenho certeza sobre a ferramenta correta a se adotar. Imagino que ao mesmo tempo deveria ser tão simples como usar uma ferramenta de escritório, fácil de se transformar em outros padrões como SGML (utilizado na documentação oficial), fácil de agregar novos colaboradores como uma ferramenta Wiki e tavez tão universal como o Google Docs.
• Precisa de um case real a ser desenvolvido. Para que os exemplos se tornem consistentes ao longo do livro, precisaríamos eleger um problema inicial a ser desenvolvido sob diferentes aspectos. Num determinado ponto do livro, chegaríamos a um pequeno grupo de tabelas e demais objetos que seriam explorados por todo o restante do livro. Só precisaríamos definir algumas regras de negócio bem básicas para que o exemplo se desenrole pelo restante do livro. Algumas licenças poéticas poderão ser admitidas, pois algumas técnicas só fazem sentido quando temos centenas de transações concorrentes ou tabelas com milhões de registros. A minha idéia inicial seria utilizar o pagila que já é mantido pela comunidade e vai sendo atualizado conforme novas versões do PostgreSQL vão surgindo. Ele pode ser tão simples e auto-explicável quanto se queira e também pode possuir graus de complexidade bem grandes para exemplificar algumas coisas;
• O público alvo seriam novos DBAs PostgreSQL, que podem ser estudantes, desenvolvedores, administradores de sistemas ou mesmo DBAs que estejam acostumados com outros bancos de dados.
• Deve ter profundidade na sua abordagem. Se sabemos que é possível fazer de algum jeito alguma tarefa, temos que mostrar como. Isto significa ter de desenvolver scripts e procedimentos em diversos pontos, bem como demonstrar a sua utilização com testes reais.
• Citar com cuidado e precisão. Realizar citações com links para a origem com a maior freqüência possível e apenas de fontes com boa credibilidade.

Possíveis tópicos a serem abordados:

• Implementando uma aplicação:
  • Ferramentas de trabalho: editores de texto em Windows e *nix, em modo gráfico e texto, formas de se trabalhar no dia-a-dia.
  • Modelagem básica: criação de tabelas, PK, FK;
  • Padrões de codificação: case sensitive, nomes para objetos, codificação explicita X implícita;
  • Domínios e tipos de dados;
  • Sequências e o uso de chaves artificiais e naturais;
  • ORDER BY, WHERE, GROUP BY, usos práticos;
  • Visões e visões atualizáveis (utilizando o RULEs);
  • Dados hierárquicos, abordagens possíveis;
  • Exportação de dados com dump, copy e PL;
  • Joins e subselects na clausula FROM, WHERE e SELECT;
  • Trabalhando com números: Localização, formatação;
  • Trabalhando com data e hora: Localização, internacionalização, conversão, formatação;
  • Trabalhando com texto: codificação de caracteres, internacionalização, conversão, formatação e manipulação;
  • Busca textual;
  • Desnormalização controlada: Gatilhos, funções e visões materializadas;
  • Uso de esquemas;
• Trabalhando com dados binários:
  • Tipos de uso por tamanho de arquivos, volume total, tipo de acesso e concorrência;
  • Uso do Bytea, OID e sistemas de arquivo;
  • Desempenho, flexibilidade e confiabilidade;
• Autitoria:
  • Campos de auditoria;
  • Tabelas de auditoria;
  • Logs de auditoria;
  • Ferramentas de auditoria;
• Segurança:
  • A rede, o SO, o PosgreSQL e a aplicação;
  • Ambiente de produção, homologação e testes;
  • Arquitetura da aplicação e estratégias de autenticação;
  • Encriptação de dados;
  • Obfuscando código;
  • Contornando falhas de segurança;
• Monitoramento de usuários:
  • Descobrindo o que os usuários estão fazendo no banco;
  • Locks de tabelas;
  • Uso de índices e estatísticas de uso;
  • Logs externos ao banco;
• Backup e Alta Disponibilidade;
  • Escolhendo a melhor estratégia;
  • Backup Lógico;
  • Transferindo dados entre bases;
  • Backup físico off-line;
  • Point-In-Time-Recovery;
  • Backup físico on-line;
  • Stand by;
  • Replicação assíncrona;
  • Replicação síncrona;
• Discos:
  • Planejando o volume de dados;
  • Particionamento do servidor;
  • Volumetria e monitoramento;
  • Distribuição de carga e uso de Tablespaces;
  • Sistemas de Arquivo;
  • LVM;
  • RAID por software e hardware;
• Instalação e Manutenção:
  • Compilação X Pacotes binários;
  • Testando e migrando de uma nova versão;
  • Flexibilidade para o ambiente de testes;
  • Segurança para o ambiente de produção;
  • Simetria entre ambientes;
  • Isolando ambientes no mesmo servidor;
  • Autovacuum manual, automático, full;
  • Reindex;
• Integrando aplicações:
  • DBLink;
  • DBILink;
  • Cargas de dados com dump, copy , via aplicações e outros métodos;
  • Validação, e auditoria na integração;
• Desempenho:
  • EXPLAIN e ANALYZE;
  • PREPARED STATEMENT;
  • Subconsultas;
  • Monitoramento avançado;