(english)

Tenho encontrado, em news e em listas, algumas discussões com referência a modelagens orientadas a objetos perante modelagens relacionais. Já passei por bons e maus bocados com cada uma destas abordagens, e este post descreve um pouco de problema e de solução que cada uma delas traz para o dia a dia de um programador.

A abordagem relacional trata a informação da forma que ela é armazenada e da forma que ela é apresentada. Esta simplicidade transforma-se em alguma produtividade com custo mínimo no aprendizado. O modelo não faz “curvas”, não é transformado. A lista de registros no banco torna-se a lista de registros na aplicação, e cada linha da lista possui informação para preencher um formulário. Simples assim.

A primeira, segunda e terceira formas normais dividem a informação de forma que ela possa ser armazenada em bancos relacionais. Cliente de um pedido ganha sua própria tabela, os itens do pedido ganham outra, e a aplicação acompanha a evolução do banco de dados. Regras de negócio tratam clientes de um pedido através de seu ID, joins trazem clientes junto a pedidos, componentes lêem os registros do banco para que a query possa ser construida com alguns clicks. A query, não, as queries. Para cada tabela, a aplicação possui um insert, um update e um delete.

Embora o modelo relacional tenha outros problemas, como ter que construir e dar manutenção em diversas queries, seu calcanhar de aquiles está na distância que existe entre ele e a informação do mundo real. No mundo real, um avalista de uma abertura de crédito pode ser tanto uma pessoa quanto uma empresa, sendo que pessoa e empresa são entidades diferentes. Para que a relação possa existir no modelo relacional, ou a empresa e a pessoa dividem a mesma tabela e compartilham os mesmos atributos, ou ocupam três tabelas (uma comum aos dois e outras duas com informações específicas de cada um), gerando uma dificuldade do outro mundo no quesito armazenagem. Tem mais, um avalista pessoa física pode ter comportamento diferente de um avalista pessoa jurídica em uma regra para avaliação de crédito, obrigando o programador a espalhar IFs difíceis de manter.

O trato com a informação no modelo orientado a objetos é mais coerente. As regras de negócio são mais claras, mais simples de executar e manter porque tratam com objetos reais, e não com listas abstratas. Um pedido aponta para um objeto cliente, e não para um número. Este mesmo pedido possui um container com vários itens ao invés de ter uma lista de itens apontando para o pedido. Ou seja, nada de Mestre-Detalhe. Não existe aberto/fechado, editando/apresentando, bloquear/liberar, existe apenas objetos em memória que em algum momento será gravado ou descartado.

No modelo OO, o banco é quem acompanha a evolução do modelo e da aplicação, e não o contrário. Programadores se preocupam estritamente com classes e com regras, um framework é quem vai entender estas classes e regras para manter o banco.

O modelo orientado a objetos começa a ter problemas em situações específicas como atualizações em lote, pesquisas complexas, ou algo deste gênero. Enquanto, no modelo relacional, tudo fica a encargo do programador, muito do modelo OO fica a encargo do framework e este pode não comportar-se da forma que o programador espera. Ou ainda, o framework pode ter falta de algum recurso, ou o programador pode não ter habilidade suficiente para extrair do framework o que ele pode oferecer.

Este ponto, aliado a curva de aprendizado maior do modelo OO, faz com que o modelo relacional ainda seja a escolha número um de diversos programadores.