FISL10: Documentação automática no PostgreSQL

Essa palestra foi apresentada por Leandro Dutra, que trabalha a mais de 10 anos com PostgreSQL, e foi muito interessante, pois lançou algumas idéias muito inovadoras ao atual modelo de modelagem de dados. Eu consideraria até que são idéias um pouco revolucionárias, pois estariam em desacordo com o que a gente aprende como “correto” em cursos de nível superior, etc.

Inicialmente, o Leandro listou as ferramentas tradicionais de modelagem de dados, que usamos:

- Cérebro, ou seja, inicialmente pensamos e imaginamos como será nossa implementação;

-  Livros-textos e documentação;

- Caneta e papel, ou seja, o ideal é que você faça um esboço inicial em papel, sem o comprometimento de ter que gravar isso;

- Programas de diagramação: nesse caso, ele não gosta de usar a palavra programas de modelagem de dados, porque ele acredita que estas ferramentas são muito improdutivas e não conseguem criar um bom modelo referencial para ser usado no banco de dados, sem mencionar que produzem um monte de código desnecessário na hora de importar para o banco de dados;

- Por fim, DDL (data definition language), que seria a linguagem de definição de dados.

Para o desenvolvimento da base de dados, o palestrante sugere aplicar a programação literária, ao invés de processo tradicional de desenvolvimento (esse processo tradicional, seria compostos por passos rígidos, como levantamento de requisitos, criação de um modelo, criação de diagramas, etc).

Na programação literária, ao invés de se elaborar um diagrama da base de dados, partiria direto para a modelagem dos dados em código fonte e após a implementação seria gerado os gráficos do diagrama, bem como toda a documentação da base de dados. Essa modelagem combinaria documentação com código fonte, com alguns identificadores, para que o computador pudesse separar os dados pertinentes a ele, quando necessário.

Para essa modelagem em código fonte, o palestrante sugeriu:

- O próprio PostgreSQL;

- ISO SQL;

- D4: no caso, o D4 seria um padrão muito interessante, na opinião do Leandro, pois ele não teria as limitações do SQL, conseguindo normalizar todas as regras do negócio, mas é algo que não está 100% pronto, tão pouco tem boa documentação.

Para a fase de geração dos diagramas e documentação, ele sugeriu:

- Autodoc, específico do PostgreSQL, com suporte a gerar gráficos, docbook e html;

- SQL::Fairy, um módulo do Perl, capaz de gerar gráficos e código em latex, com a grande vantagem de se comunicar com praticamente qualquer tipo de banco de dados, bem como converter para qualquer saída que se deseje;

-SchemaSpy, uma solução em Java, que gera HTML, com a vantagem de ter uma inteface gráfica para ajudar na hora de gerar a documentação da base de dados.

Algo que o palestrante deixou bem claro é que para isso funcionar é necessário usar muito definição de domínios.

Para finalizar, algumas curiosidades:

O Brasil está em terceiro lugar em importância de uso de PostgreSQL (boa parte por causa do CASE da CEF), sendo que em primeiro está o Japão e em segundou lugar os USA.

Sobre a CEF, ainda, ele disse que a solução deles de 750TPS (transações por segundo), corresponde, aproximadamente, a 1500 transações no banco de dados por segundo.

Uma dica que ele deu sobre a modelagem de dados é tentar usar muito chave natural, ao invés de joins tradicionais, pois além de melhorar a visualização das consultas, isso pode ajudar a melhorar o desempenho também.

Tags: Banco de Dados, Desenvolvimento, fisl10, PostgreSQL