MySQL Anoyances

Descobri mais uma amolação do MySQL, o nome das tabelas é case sensitive. Até ai, nada de muito grave, muitas linguagens de programação são case sentives e as pessoas se habituam a utilizar convenções, porém, o MySQL só é case sensitive se o filesystem o for (lembrem-se que no MyISAM cada tabela é um arquivo), ou seja, o programa idiota passa para a o fopen o nome da tabela como o usuário digita no SQL.

Tive que implantar um sistema que foi desenvolvido em que uma tabela é referenciada com diferentes convencões de case em diferentes partes do sistema. Como o sistema provavelmente foi desenvolvido no windows, esse problema passou despercebido.

Por sorte o script que criava o banco não especificava o Engine a ser utilizado, por isso eu pude editar o my.cnf para que o InnoDB fosse o engine default, e neste caso a lower_case_table_names=1 faz com que o MySQL seja case insentitive [1].

Aproveitei para corrigir outra chateação, o MySQL vem configurado como latin1 (até ai tudo bem) e ordencão de palavras em Sueco (??????). Para um configuracão razoável é preciso adicionar as seguintes linhas no my.cnf:

character-set-server=utf8
collation-server=utf8_general_ci


[1] http://dev.mysql.com/doc/refman/5.0/en/identifier-case-sensitivity.html

Aprendendo ruby

O Akita passou hoje na minha mesa e me disse que publicou um micro tutorial pra iniciantes em ruby como eu. É um micro-tutorial-não-tão-micro em três partes.

Ioke

Acabou de sair na InfoQ, uma entrevista com o Ola Bini sobre o ioke, uma nova linguagem dinâmica que roda sobre a JVM. A entrevista da InfoQ é muito boa, vale dar uma olhada.

Uma passada rápida pelos meus feeds antes de ir pro trabalho ...

Bancos de dados orientdos a objeto

O banco de dados é um elemento que dificulta o desenvolvimento ágil. Em primeiro lugar existe a impedância entre o mundo relacional e o mundo dos objetos, o segundo é a sincronização do esquema do banco com o código.

O primeiro problema pode ser resolvido parcialmente através do ORM, Object Relational Mapping, que é a abordagem do ActiveRecord, do Hibernate e outros. Essa não é uma solução completa, não existe, por exemplo, nenhuma solução totalmente satisfatória para mapear a herança dos objetos nas tabelas do banco de dados relacional.

O problema de sincronização possui soluções menos satisfatórias ainda. No mundo do java existem gerados de código que olham para o banco e geram os objetos, o que é uma péssima solução, já que é muito fácil desincronizar o código gerado. O ruby soluciona o problema gerando dinamicamente as classes apartir das tabelas, portanto o programador faz alterações no esquema do banco e estas são refletidas dinamicamente no código. O problema dessa abordagem é evoluir o esquema do banco, o que pode ser feito de duas maneiras: editando diretamente o banco através de uma ferramenta como o MySQL Query Browser ou o PgAdmin, etc, o que faz com que se perca completamente o histórico de mudanças, ou então utiliza-se algo como as Migrations do ruby, que também não são triviais de manter.

Todas esses problemas desaparecem com um banco de dados orientado à objeto, basta declarar a classe, armazena-la no banco e pronto. As mudanças também são triviais, no sistema que eu testei, db4o, ele detecta automaticamente mudanças nas classes e atualiza do banco de dados da maneira apropriada. Em termos de facilidade de desenvolvimento um OODBMS (Oriented Object Database Management System) ganha muito em relação à um RDBMS (Relacional Database Management System). Porém existe um custo, a performance das operações é muito diferente entre os dois tipos de bancos de dados, o banco orientado à objetivo é muito rápido para carregar objetos com um grafo complexo, porém operações de agregação (sum, count, group by) são muito mais rápidas no banco relacional.

Dependendo do tipo de aplicação que se deseja desenvolver, um OODBMS pode dar ao programador alguns graus de liberdade a mais.