Wednesday, November 05, 2008

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.

1 comment:

djogo said...

Opa! Bom post!

Existe um truque (caching) com duas possíveis implementacões para resolver o problema de velocidade em databases orientados a objeto:

1) criar tabelas relacionais que são atualizadas sempre que o objeto é atualizado (com "triggers" do objeto), ou a cada x dias

2) fazer cache de buscas frequentes

é isso que eu tenho visto o povo fazer no problema do prontuário médico: 600 mil pacientes, cada um com 700 documentos XML, como fazer uma busca?