O que você precisa saber sobre Bancos de Dados Relacionais

O que você precisa saber sobre Bancos de Dados Relacionais

Tire suas dúvidas sobre o assunto

Prós e contras dos Bancos Relacionais

Em todo lugar a gente vê alguém falando apaixonadamente sobre as vantagens deste ou daquele banco de dados. O problema é que tecnologia não pode ser analisada com paixão, porque precisamos ter certeza de quando e como ela será adequada para nós.

Neste artigo eu comento algumas questões importantes sobre o uso dos bancos de dados relacionais (que chamarei de BDRs daqui para a frente). Apresento, também, os pontos fortes e as deficiências desses produtos.

Como funcionam

A ideia dos BDRs é gravar a informação na forma mais elementar possível, com o objetivo de evitar redundância, reduzir o risco de inconsistências e, consequentemente, reduzir o volume total de dados armazenados.

Entre os produtos mais conhecidos desta categoria estão SQL Server, MySQL, PostgreSQL, Oracle e IBM DB2.

Caso você nunca tenha visto um BDR, pode imaginá-lo como sendo uma coleção de pequenas “planilhas” que se relacionam entre si. Chamamos essas “planilhas” de tabelas. As colunas das planilhas são chamadas de campos e suas linhas, aquelas que contêm os dados, são chamadas de registros.

Veja o exemplo de um modelo bem simples da estrutura de um banco que trata do estoque e das vendas (ou seja, descrição das tabelas e campos envolvidos).

Com esta estrutura não é necessário, por exemplo, escrever o nome do cliente na tabela de notas fiscais (aqui chamada tblInvoice). Basta apenas gravar o seu código, porque existe uma tabela que contém todas as informações sobre o cliente (tblCustomer). Como se pode ver, estas duas tabelas se relacionam por meio do campo codCustomer que existe em ambas.

Pontos positivos

BDRs dominam o mercado há, pelo menos, 20 anos. Isso tem uma série de consequências, entre elas:

  • Tecnologia amadurecida.

  • Há produtos para todos os “bolsos”: existem opções de código aberto, os de licença gratuita e, obviamente, os produtos comerciais.

  • Existem muitos profissionais qualificados: é bem fácil encontrar informações técnicas na internet ou mesmo obter suporte em fóruns especializados.

  • É a tecnologia mais usada em aplicações de missão crítica pelo mundo afora.

  • Aproveitam muito bem o espaço em disco (isso porque surgiram numa época em que armazenar dados era muito caro).

  • Não há absolutamente nenhuma evidência que sugira que os BDRs não permaneçam no mercado por, pelo menos, outros 20 anos.

Há tanta informação gratuita na internet que é bastante provável que você encontre um modelo de projeto parecido com aquele que deseja construir. Dê uma olhada no site DatabaseAnswers.org. Lá você encontrará cerca de mil modelos gratuitos de BDRs voltados para as mais diversas áreas de negócio.

Pontos negativos

Sou fã dos BDRs, mas eles têm algumas limitações sérias que podem causar grandes problemas em algumas situações.

Em primeiro lugar, eles não são bons para armazenar dados com formatos especiais, como dados de geoprocessamento e objetos binários grandes (ou BLOBs), que incluem todo o tipo de arquivo (PDF, XML, XLS, DOC etc.). Quase todos os BDRs têm “extensões” que ajudam o mecanismo relacional a lidar com estes dados, mas estas soluções, geralmente, criam uma espécie de Frankenstein.

Mas a limitação que considero mais importante provém do fato de que os BDRs tratam dados de um modo bastante formal, especificando o tipo de dado de cada campo (texto, datas, números etc.) e a posição da tabela onde deve ser gravado (ou seja, em qual campo). Isso resulta em uma série de exigências, por exemplo:

Dados não são gravados individualmente, mas sim num conjunto chamado “registro”.

  • O registro inclui, obrigatoriamente, todos os campos previstos na tabela;

  • O registro, necessariamente, tem de conter dados com os tipos de dados adequados para cada campo (se o campo é do tipo inteiro, não se pode escrever letras ali);

  • O registro, necessariamente, tem de seguir a sequência dos campos existentes na tabela (caso o programador prefira uma sequência diferente, ele é obrigado a informar qual sequência está considerando).

Estas exigências podem não parecer muita coisa, mas têm um impacto muito grande no ciclo de vida de um sistema de informação. Atualmente, as empresas são muito dinâmicas e frequentemente os sistemas precisam ser alterados para refletir novas necessidades.

Para o banco de dados, estas novas necessidades, geralmente, implicam a criação de novas tabelas ou novos campos nas tabelas já existentes. Além disso, as aplicações também precisam ser corrigidas e o “alinhamento” entre as alterações de banco e a aplicação precisa ser testado. Este processo todo é demorado e caro, duas características extremamente negativas no mundo de TI e no mundo dos negócios.

É bastante provável que sua aplicação não tenha grandes exigências em termos de frequência de atualização. Essa limitação, portanto, não deverá ser um problema para você.

Conclusão

Quer dizer que BDRs são sempre a solução mais indicada?

Não. Isso depende das características de cada projeto.

Por mais versáteis que sejam os BDRs, existem situações em que outras opções são mais adequadas. Entre elas estão os bancos de dados NOSQL, mas isso é assunto para o próximo artigo.

Até lá!