Há algum tempo eu escrevi sobre a lei dos 80-20 por aqui. Mas após uma conversa com o Everaldo Canuto, fiquei com vontade de escrever novamente sobre isso. Existem dezenas de linguagens disponíveis e utilizadas com frequência. Algumas tem nichos específicos de mercado como LISP, LUA ou AWK. E várias outras concorrem por fatias semelhantes de mercado. Em Banco de Dados, as coisas mudam, existem poucos fornecedores de SGDB que se destacam no mercado. Além disso, existe uma vontade mais que justificada de centralizar todos os dados de uma instituição no mesmo banco de dados. Administrar um ambiente com vários SGDBs de fornecedores diferentes é uma grande dor de cabeça, embora isto quase sempre ocorra. Mesmo assim, usar a ferramenta adequada para cada problema parece algo que merece ponderação. Existem inúmeros projetos em que a escolha do SGDB utilizado sequer passa por uma verificação das características realmente desejadas. Vejamos algumas opções que podemos utilizar e nem sempre são citadas:
Arquivos texto
Quem disse que não dá para fazer um monte de coisas bacanas guardando as informações apenas em arquivos texto? Por trás da cortina, há uma infinidade de programas que guardam seus dados em arquivos texto. Em aplicações de desktop, monousuário com uma quantidade de dados pequena e pouco complexos, os arquivos texto podem ser muito vantajosos. Arquivos de configuração são um exemplo comum, mas aplicações que trabalham com um pequeno volume de dados e poucas tabelas podem utilizar arquivos texto com tranquilidade.
Vantagens:
- Tecnologia de domínio público
- Praticamente toda linguagem de programação possui funções embutidas para ler e gravar dados em arquivos texto
- Com um volume de até alguns milhares de linhas, o acesso pode ser bem mais rápido e simples que em um SGDB tradicional;
- Você pode utilizar formatos como XML, CVS e outros que podem ser importados e exportados por outros programas facilmente.
- Ocupa pouco espaço, é simples de realizar backup e consome poucos recursos da máquina.
Se você precisa usar uma quantidade maior de dados e quer o poder de uma linguagem SQL na mão, o SQLite pode ser a solução! Não é um SGDB, é uma biblioteca leve que você utiliza junto com o seu programa. Se você tem uma aplicação local como um site web com até 100 mil hits por dia, até 1GB de dados e poucas gravações concorrentes, o SQLite uma opção imbatível.
Vantagens:
- Licenciado como Domínio Público
- SQL e ACID
- Apenas um arquivo para todo o banco de dados
- Ocupa pouco espaço em disco (cerca de 250Kb)
- Consome poucos recursos da máquina
Você tem uma estrutura de dados mais rígida e está preocupado com velocidade, transações concorrentes, replicação e precisa fazer tudo isso com hardware limitado? O BDB é uma biblioteca assim como o SQLite, mas com características menos flexíveis e mais robustas. É excelente em aplicações embarcadas e uma opção natural para serviços de diretório e outras aplicações, Você não tem uma linguagem de consultas como o SQL, tudo tem de ser definido via programação, você tem liberdade de definir estruturas totalmente adaptadas para a sua aplicação. Se você pode abrir mão da flexibilidade do SQL e precisa de desempenho e robustez, o BDB é uma escolha imbatível.
Vantagens:
- Licença permite uso sem custos para aplicações com licenças livres ou para uso local
- ACID, controle de transações avançado com MVCC
- Replicação
- Consome poucos recursos com bom desempenho
Ok, você precisa de um SGDB com todas a flexibilidade do SQL, funções, gatilhos, ACID, índices avançados e suportar diferentes aplicações com confiabilidade e robustez. O PostgreSQL é provavelmente um bom candidato. O PostgreSQL tem crescido com muita força nos últimos 10 anos e já provou que é capaz de suportar aplicações pesadas com bom desempenho.
Vantagens:
- Licença BSD
- Excelente conformidade com o padrão SQL
- PL/pgSQL, PL/python, PL/Perl, PL/Ruby, PL/Java e outras linguagens procedurais
- Replicação com Slony, pgPool e Hot Stand By
- Particionamento de tabelas, MVCC, GiST, Tablespaces, Point In Time Recovery e outras funções avançadas
Há casos em que nenhuma destas soluções pode servir… em aplicações muito específicas, com grandes exigências de clusterização ou onde as demandas de integração com SGDBs já existentes são impressindíveis. Antes de pensar em sair comprando licenças da Oracle, DB2 ou Teradata, verifique quais são as suas reais necessidades. O fato é que muitas pessoas tem medo de adotar uma solução de um fornecedor que não gaste milhões de dólares em propaganda todos os anos. Antes de dizer que determinada solução não serve, teste e homologue. Mesmo no mundo lento e conservador dos bancos de dados as coisas mudam. Mudar pode significar uma implementação mais rápida, simples ou até um diferencial no mercado para o seu produto.
Deixe um comentário