Sistema Gerenciador de Banco de Dados baseado em arquivo?

Você pode usar algum banco como o Derby ou JavaDB (que vem com o próprio JDK a partir da versão 6), por exemplo.

Ok…estou seguindo um tutorial de como utilizá-lo offline.

Obrigado!

Mas somente para esclarecimentos, teria como usar outros…como o mySQL por exemplo?

diego_qmota:

Ok…estou seguindo um tutorial de como utilizá-lo offline.

Obrigado!

Mas somente para esclarecimentos, teria como usar outros…como o mySQL por exemplo?

MySQL não sei se funciona em modo arquivo, mas tem tb o HSQL

Bom, comecei usando o JAVA DB…apanhei um pouco, mas consegui fazer uma conexão e extrair os dados de uma consulta.

Para um começo, está bom. Só estava relutante em usar o java db no início porquê encontrar material de referência (principalmente mais claros) e ferramentas, para auxilío no manuseio, é mais dificil que para outros SGBD’S mais utilizados.

Depois vou testar o HSQL. Pelo que vi na página dele, parece que cumpre minhas expectativas… e vou precisar de um SGBD mais prático para programas que empregarão grandes quantidades de registros.

Obrigado!

Se você só trabalha com objetos tem o DB4O, se você for mais “espartano” tem o SQLite que é extremamente leve.

diego_qmota:

Boa tarde!

Alguém conhece um SGBD que eu possa empregar para substituir o MS ACCESS? Estou trabalhando com recursos que não podem mudar…e o que tenho disponível é um servidor de arquivos somente, no qual são efetuadas poucas mudanças e que não dependem de mim, e sim de um departamento de uma grande empresa que não disponibiliza no tempo suficiente o que precisamos.
Um exemplo: para disponibilizarem o SQL SERVER, estamos esperando há anos…

Desta forma, temos usado MS ACCESS. No começo, não havia grandes problemas. Mas com o passar do tempo, quando fomos criando sistemas mais complexos, que exigiam maior escalabilidade e controle de concorrências do banco, começaram a surgir inúmeros problemas, seja de gerenciamento do BD, como de integridade dos dados armazenados…

Gostaria de saber, então, para acabar com o problema, qual SGBD baseado em arquivo pode ser empregado. Um SGBD que não dependa de servidor e que possa ser acessado em rede (como um arquivo .mdb em rede, como fazemos atualmente no caso do ACCESS).
Não precisa ser um SGBD só baseado em arquivos… pode ser um SGBD conceituado que funcione das duas formas (assim, uma futura migração ficaria mais simples…)

Que bela empresa para se trabalhar hein…

Tem esse por exemplo
http://www.h2database.com/
Mas vc pode ter problema de concorrência, não sei se com os outros vc terá (hsqldb, derby…)

O JavaDB é um pouco pesado, mas ele tem uma vantagem que é o fato de permitir arquivos de dados criptografados. Pode ficar um pouco mais pesado, mas muitas aplicações precisam disso. (Imagine se alguém fica “fuçando” nos arquivos da aplicação e resolve editar alguns dados manualmente, como salários )

O Firebird é baseado em arquivo. Nao sei se resolve o teu problema, mas da uma olhada.

É, eu percebi na hora que fui fuçar nesses arquivos, para conhecer a estrutura. Isso é um grande ponto positivo!

Bom, fiz um pequeno programa com o JAVA DB. Rodou legal. Mas tive dificuldades para criar PROCEDURES, já que sabia criar com a linguagem do SQL Server (PL / Transact SQL), e nao consegui mesmo criá-las agora…

Vou considerar todas as sugestões…o que procuro mesmo é um banco que tenha bom desempenho, mesmo sendo baseado em arquivos, e que suporte quantidades muito grandes de registros. Além disso, ele será acessado em rede, mas em um servidor de arquivos (por isso têm que ser em “arquivo”) - ou seja, terá que suportar bem concorrência.

Bom, obrigado pelas sugestoes. Vou tentar empregá-las em cada novo projeto.

É, eu percebi na hora que fui fuçar nesses arquivos, para conhecer a estrutura. Isso é um grande ponto positivo!

Bom, fiz um pequeno programa com o JAVA DB. Rodou legal. Mas tive dificuldades para criar PROCEDURES, já que sabia criar com a linguagem do SQL Server (PL / Transact SQL), e nao consegui mesmo criá-las agora…

Na boa, não use StoredProcedures. Dessa forma vc terá mais facilidade em programar e terá um aplicativo independente de banco.

Eu já acho o contrário… Mas nesse ponto você está certo: facilita a portabilidade para outro banco, sem dúvida.

Mas não creio nesse ponto de facilidade em programar…porquê vou ter que automatizar várias tarefas de gerenciamento e programar muito…muito mais do que se simplesmente concentrasse todas as tarefas em Stored Procedures e chamasse elas pelo aplicativo…

Pelo visto essa questão de recursos é uma briga na tua empresa.

Já pensou se o pessoal decide ouvir vcs e instalam um MySql ou Postgres ‘bunitinho’ para uso,
e vcs terão todo o esforço para migrar para algum desses bancos?

Como foi dido, tente ficar independente de banco, é claro que as vezes não dá, mas não faça
disso uma regra.

Ok. Vou tentar. Mas no momento, vou ter que testar um por um. Obrigado pela dica!