I Dia PostgreSQL São Paulo (2009)

Dia vinte e quatro de abril, sexta-feira próxima, será o I Dia PostgreSQL de São Paulo (2009), SP, Brasil. Vou apresentar as ferramentas de documentação automática de modelos e bases de dados PostgreSQL, espero que de maneira mais objetiva que o que consegui fazer na II Conferência Brasileira de PostgreSQL (2008), em Campinas.

Como sempre nos eventos dessa comunidade, haverá alguns ótimos palestrantes, como o Euler e o Guedes; desta vez teremos também o próprio organizador do evento, o Rodrigo Marins, possivelmente o Leonardo César, e um DBA da Caixa Econômica Federal. Parece que será bem interessante.

Pretendo abordar programação literária em NoWeb (en passant), mas principalmente Auto Doc, assim como um pouco do SQL Fairy e do Schema Spy.

O evento é gratuito, portanto a única desculpa para não ir é ser uma sexta-feira de trabalho. É uma semana curta por causa do feriado do Descobrimento do Brasil na terça-feira, dia vinte e um, o que pode ajudar — deve ser uma semana lenta de trabalho — ou atrapalhar — algumas pessoas podem ser atropeladas justamente pela falta de tempo na semana para liqüidar alguma tarefa urgente e inadiável. O lugar é um pouco remoto, a Lapa de Baixo, perto da Marginal do rio Tietê; mas, numa semana curta, esperamos que o trânsito não esteja ruim.

Leonardo César e os softicidas

Conversa esses dias com o Leonardo César:

Eu: O que é isso?

LC: Isso o quê?

Softcida…

cida = assassinos (?)

E quem são os tais? Maus programadores, gestores, o quê?

Sim, estes mesmos…

Estes últimos, os gestores… certo!

Veja bem, estamos desenvolvendo uma arquitetura bem complexa e distribuída através de webservices (SOAP). Isso envolve alguns bancos e seguradoras e estes normalmente estão utilizando Java ou .Net. O problema é que as ferramentas geram os clientes automaticamente, baseado no WSDL.

Uau! Mas e aí?

E estas ferramentas não são compatíveis com a especificação padrão WSDL e os "programadores" não fazem a mínima questão de ler a especificação e ver que a ferramenta deles não gera o cliente porque fogem do padrão… e daí eu que preciso adequar o WSDL às ferramentas de todos os clientes… por isso odeio softcidas…

Isso me fez lembrar adivinhem o quê? Hybernate!

Pode parecer à primeira vista não ter nada a ver. Mas tem: alguém faz ferramentas de qualquer jeito, sem levar em conta os conceitos e padrões fundamentais, tornando-se um softcida, que vai gerar muito mais problemas do que aparentemente resolve.

Usar Hybernate é cometer softcídio, porque os resultados são terríveis assim que se precisa escalar, e geralmente muito antes, por causa da inconsistência de dados. Evite Hybernate, previna o softcídio. Aprenda dados e SQL.

Administração de dados: codificação de caracteres

Codificação de caracteres. Não deve haver assunto mais insistente na lista brasileira de discussões. ASCII, Latin1 e UTF-8 estão sempre em discussão. Mas alguém pode dizer: ‘Isso não é um problema de administração de dados, mas físico! É uma questão do que é mais eficiente!’ Mas não — a codificação de caracteres limita o que pode ser codificado, e portanto um administrador de dados, sempre que possível, vai querer usar o que for mais flexível, que não estabeleça limites arbitrários.

Ainda tem gente brigando com bases de dados em ASCII. Tipicamente, porque instalou um sistema operacional sem configurar a língua, ficando com as configurações por omissão, ou seja, o local ‘C’. O problema é que o ASCII é 7 bits, portanto codifica apenas 128 caracteres — o que, devido a caracteres de controle, não imprimíveis, pontuação e acentuação para línguas mais votadas, não cobre todos os caracteres da língua portuguesa. Ou seja, é verboten!

A opinião mais corrente parece ser a de que ‘não se precisa mais que Latin1 no Brasil’. Errado! Latin1, cujo nome correto é ISO 8859-1, está obsoleto: por exemplo, não consegue codificar €, o símbolo do Euro. Ou seja, proibido também.

Então, dirão, vamos de Latin9, ISO 8859-15. Sim, é uma escolha razoável. Mas imagine que chegue um chinês maluco, goste de seu programa, e decida levá-lo para a China. Pena, você acabou de perder o negócio de sua vida. E se teu chefe decidir expandir negócios para a Índia, e descobrir que você criou um sistema que só serve para o Ocidente? Pena, você vai ter de procurar outro emprego.

Isso nos deixa com Unicode, do qual a escolha mais razoável no Ocidente é o UTF-8. Sim, UTF-16 é mais consistente, mas além de ser o único suportado pelo PostgreSQL, ocupa apenas um byte para os caracteres ocidentais, que costumam ser a grande maioria, exceto para aplicações estritamente locais do Oriente. E, se você tem algum problema em usar UTF-8… bom, ele suporta qualquer codificação, então certamente é um problema estritamente de aplicação, configuração, até um possível defeito no PostgreSQL ou alguma biblioteca relacionada, mas certamente não é um problema do UTF-8 em si.

Resumindo, a menos que você precise de algo muito, muito específico mesmo, faça-se um favor — Unicode na cabeça.

Administração de Dados: tipos & domínios

Seguindo a série sobre os fundamentos da gestão de dados, falemos sobre os tipos de dados.

Fico impressionado com a quantidade de ‘ferramentas de modelagem de dados’ que não passam de diagramadores — porque não suportam o conceito mais básico depois da própria teoria de dados, que é o de tipagem.

Há muita confusão neste campo por erros terminológicos de ferramentas, métodos e mesmo padrões. Por exemplo, quase todos os sistemas de informática suportam alguns tipos de dados — mas geralmente são apenas alguns poucos tipos básicos, não extensíveis pelo usuário. E quando há essa extensibilidade, chamam-nos tipos abstratos de dados, como se houvesse outros tipos não abstratos. Confundem-se tipos com sua representação, de modo que duas representações são tratadas como tipos diferentes. E, por fim, chamam-se domínios a simples nomes dados a determinados tipos básicos, talvez com algumas restrições de integridade associadas.

Ora, tipos nada mais são que domínios e seus operadores associados; enquanto domínios são listas de valores (não necessariamente discretos) nos quais se pode definir um atributo. Assim, os domínios ISO SQL não são domínios de verdade, e o conceito realmente útil seria o de tipos, mas que também não é realmente suportado, e o que é suportado é de difícil implementação.

Sem uma definição de domínios centralizada no SGBD ou ao menos na ferramenta de modelagem, cada relação do modelo vai tender a ganhar diferentes definições para os mesmos tipos de dados, e o caos é o limite. Sem contar as comparações e cálculos absurdos que se fazem entre tipos de dados incompatíveis.

Em PostgreSQL temos uma sorte: os tipos são um pouco melhor implementados que noutros SGBD ou mesmo no padrão ISO SQL, e em combinação com os domínios SQL realmente se aproximam do conceito matemático. Duro é trabalhar num projeto que realmente implemente os tipos e aloque um programador (C ou D, por exemplo) para criar os tipos assim que possível, antes do resto da programação e implementação da base de dados.

O suporte, embora imperfeito, está aí. Mesmo que tipos SQL muitas vezes não sejam práticos, pelo menos seus ‘domínios’ ajudam. Agora não me venham com diagramas bonitos chamando-os de modelos, se pelo menos os domínios não estão definidos! Quase cem por cento de probabilidade de que, se já não houver grandes inconsistências, elas logo ocorram ao longo da vida da aplicação.

Administração de Dados: os fundamentos

Gostaria de saber dum bom livro-texto de administração de dados. Faz falta, mesmo já com muitos anos de estrada, e mesmo tendo livros tão bons sobre modelos de dados quanto o do Date. Acontece que a ênfase dos livros costuma ser tecnológica; e mesmo um livro conceitual (e conceituado) como o do Date usa os conceitos como base para aplicações tecnológicas, não conseguindo — afinal, trata-se apenas de um livro-texto, não uma enciclopédia de gestão de dados — se preocupar com o projeto e manutenção dos modelos específicos de dados.

Aliás, também gostaria de ter mais contatos na área, a abrangência de meus interesses acaba prejudicando esse corpo-a-corpo tão necessário no Brasil.

Enfim, farei aqui algumas anotações, na esperança de que alguns colegas vejam e comentem.

Primeira anotação: qual o fundamento mais importante da administração de dados?

Resposta irrefutável, mas que virá como surpresa para os empiricistas: uma teoria de dados.

Muita gente começa até com um bom entendimento dos dados em si no sentido de que conhece a aplicação e os usos que fará de que dados. Mas acaba fracassando na organização desses dados, e criando sistemas que não escalam, que são xingados por usuários e mantenedores, que têm de ser refeitos várias vezes até se tornarem aceitáveis, por faltar uma teoria de dados. Daí também vêm tiros no pé como bases de dados multivaloradas (Pick, Caché), navigacionais (Clipper, BTrieve) e orientadas a objeto (Jasmim, de novo Caché). E coisas mais estranhas ainda, como o ReiserFS (não a implementação atual, mas o objetivo final).

Aqui não é o lugar para justificar o modelo relacional como única teoria de dados válida, nem para criticar os outros. Então meus (eventuais) leitores terão de fazer a tarefa de casa, que consiste em ler —­ de preferência, o Date supracitado — e pensar muito.