A volta do Clipper 5.x com DBF
Recentemente li uma matéria sobre o JavaDB, um banco de dados completo, baseado no projeto Derby da Apache e que pode ser embutido na sua aplicação. Bom, o curioso é a Sun colocar na página do produto um comentário um pouco “contraditório” (entre aspas mesmo, eu chego lá…)
Se a gente pensar bem, o tempo todo dizem que devemos evitar bancos de dados departamentais, vamos integrar! Vamos agrupar tudo! Facilitar a administração, evitar a replicação e todas aquelas coisas que os fornecedores de produtos nos fazem acreditar. Qual o resultado? Ninguém quer sair da faculdade e trabalhar numa aplicação pequena e simples! Todo mundo quer trabalhar numa aplicação “Enterprise Server,” mas aà quem vai cuidar de todos os clientes que também precisam de soluções de TI, mas não tem o poder de compra das grandes corporações?
Nesse contexto o software Open Source se faz, geralmente mais barato (para casos simples onde não precisamos levar o software ao extremo). O JavaDB oferece essa facilidade, softwares pequenos e simples com o poder de SQL conforme conhecemos. O curioso é que isso era oferecido há 10 anos atrás com Clipper e DBF em máquinas 386…
Infelizmente o custo de um ambiente desses na época é o mesmo que temos hoje para rodar uma aplicação Java, com JavaDB em um Desktop Dual Core.
A única coisa que ninguém comenta é que se a sua aplicação pode ser feita com JavaDB provavelmente também pode ser feita com DBF e Clipper e rodar num 386, ainda hoje.
mas a questao na epoca do clipper do ponto de vista de desenvolvimento, era que as consultas eram realizadas em um um nivel mais baixo tipo: no maximo a gente conseguia ter un indice, para filtrar os dados era manualmente, com o SQL isto fica uma pouco mais simples…
mas falando em simplicidade nao seria o HsqlDB mais maduro que esta solucao do JavaDB ?
http://hsqldb.org/