Boa tarde! Preciso de um banco de dados bom para acesso em uma rede local, mas como não há um SGBD e não tenho como colocar um (se houvesse a possibilidade seria o ideal, mas não dá para colocar mesmo), preciso colocar um baseado em arquivo mesmo (parecido com os bd´s embedded).
Ele deve permitir acesso concorrente também, sem maiores problemas.
Por incrível que pareça, o único que cumpriu esse requisito até agora foi o MS ACCESS. E é o único que tô tentando fugir também…
Obs: Já tentei usar o H2, e ocorre o seguinte:
as aplicações clientes funcionam concorrentemente, aparentando que tudo transcorrerá sem maiores problemas;
quando é executada uma ação de insert ou delete que afeta muitos registros, e havendo aplicações concorrentes acessando o banco, ele corrompe os arquivos de dados;
E isso toda hora (mesmo usando file_lock = no e mvcc = true - para quem conhece o H2). Quando é só consulta, ele funciona bem e é excelente. No entanto, o suporte para concorrência em atualização de registros, em versão embedded, parece ser muito ruim. Por isso, H2 e HSQLDB eu já desisti, já bati a cabeça com eles e não resolveram…
O que você quer um banco mysql, Postgresql, atendem mas qual o motivo de não poder usa-los? Outra sugestão, tem de ser relacional, Já ouviu sobre CouchDB, ele é orientado a documentos.
D
diego_qmota
Por diretrizes internas da empresa, a área de TI não disponibiliza um SGBD e não permite acesso ao servidor para instalar um.
Há um departamento pequeno que têm a necessidade de um sistema com acesso concorrente. E por essas limitações, têm que ser em arquivo.
Não…nunca tinha ouvido falar…
E
euprogramador
diego_qmota:
Por diretrizes internas da empresa, a área de TI não disponibiliza um SGBD e não permite acesso ao servidor para instalar um.
Há um departamento pequeno que têm a necessidade de um sistema com acesso concorrente. E por essas limitações, têm que ser em arquivo.
Não…nunca tinha ouvido falar…
Ai ficou dificil, usa clipper com dbase.
B
bezier_curve
Você poderia tentar usar o SQL Server 2005 Compact Edition e conectar-se a ele usando o bom e velho “JDBC-ODBC Bridge” - exatamente como uma aplicação que tenta acessar o MS Access.
não requer instalação e você pode utilzá-los como arquivo ou servidor.
D
diego_qmota
wbdsjunior:
tem o HSQLDB e o Apache Derby (ou JavaDB).
não requer instalação e você pode utilzá-los como arquivo ou servidor.
Esses dois aí não dá… o Apache Derby não suporta acesso concorrente (eu já tentei e “rachei” a cara…rsrsrs. O HSQLDB dá os mesmos problemas do H2 e mais alguns a mais.
não requer instalação e você pode utilzá-los como arquivo ou servidor.
Esses dois aí não dá… o Apache Derby não suporta acesso concorrente (eu já tentei e “rachei” a cara…rsrsrs. O HSQLDB dá os mesmos problemas do H2 e mais alguns a mais.
dá uma olhada no link abaixo e veja se algum destes serve.
não requer instalação e você pode utilzá-los como arquivo ou servidor.
Esses dois aí não dá… o Apache Derby não suporta acesso concorrente (eu já tentei e “rachei” a cara…rsrsrs. O HSQLDB dá os mesmos problemas do H2 e mais alguns a mais.
dá uma olhada no link abaixo e veja se algum destes serve.
Ok, vou dar uma olhada. Mas vou ter que fazer um estudo de cada um…rs
D
diego_qmota
Vou fazer um teste amanhã, para ver se o SQL SERVER COMPACT resolve o problema. Obrigado
D
diego_qmota
bezier curve:
Você poderia tentar usar o SQL Server 2005 Compact Edition e conectar-se a ele usando o bom e velho “JDBC-ODBC Bridge” - exatamente como uma aplicação que tenta acessar o MS Access.
Parece muito bom, pela descrição que li no site citado. As limitações que esta versão possuí (256 acessos simultaneos e 4GB de espaço), acomodam bem o tamanho e escopo do aplicativo que estou fazendo:
O problema com os outros bancos opensource é esse. Elas não fornecem uma abordagem segura quando o assunto são bancos embarcados para múltiplos acessos concorrentes. Eles são ótimos como banco embarcados, sem dúvida. Mas quando se fala em acesso concorrente, são poucas referências concretas que encontro.
O próprio H2, que eu gostei muito de início, têm esse problema. Eu utilizei ele para pequenos aplicativos de consulta, mesmo concorrentes, e funcionou muito bem!
Agora, que está envolvendo atualizações simultaneas, começaram os problemas. Dá para você configurar para trancar (LOCK_FILE) o arquivo ou não.
Testei com travamento do arquivo em operações de exclusão e não apresentou as falhas anteriores, embora demorou bastante para as mudanças refletirem nos aplicativos clientes… Não testei ainda com INSERT. Eu só sei que havendo uma conexão paralela, ele não executa ela se for ao mesmo tempo que há uma conexão que tranca. Vou testar ainda com o console trancando e um aplicativo cliente em outra máquina tentando acessar.
Acho que com o H2 não vira mesmo… estou com medo de usá-lo e começar os travamentos em larga escala depois…e já perdi muito tempo nessa parte do projeto…
Y
YvGa
Ja tentou o Firebird? É um banco relacional mas baseado em arquivos, voce pode acessa-lo atraves da rede. Ja o vi rodando em aplicacoes relativamente grandes sem maiores problemas.
D
diego_qmota
Eu pensei em usar o FIREBIRD sim, faz algum tempo, em outro momento que eu estava com essa mesma questão e acabei usando o ACCESS.
Eu não tentei usar o FIREBIRD por várias informações contraditórias que vi, ao pesquisar. Li um artigo no site deles que dizia que ele poderia funcionar como servidor ou em versão embedded (como o access, h2).
Eu não sei como funciona o uso que eles definem como servidor se o banco FIREBIRD é em arquivo… Fiquei encucado…se o uso como server for igual a um sgbd relacional usual (sql server, mysql, etc.) , mesmo sendo o bd em arquivo, não ia adiantar porquê precisaria de um servidor rodando o sgbd (como os bancos relacionais citados) e isso eu não tenho disponível para essa aplicação… Fiquei na dúvida agora se é isso ou se o simples fato de colocar o arquivo do bd na rede e acessá-lo de múltiplas máquinas se caracteriza como o uso como servidor? (o que seria ótimo para mim)
Para mim, esse tipo de acesso, se ele fosse igual aos SGBDS citados, só poeria ser feito usando como EMBEDDED. E vi neste artigo e em outros, que a versao EMBEDDED não poderia ser acessada por mais de 1 máquina cliente ao mesmo tempo.
Para mim, se ele suprir essa necessidade, sem problemas. É que devido a achar que só podia ser acessado por uma máquina de cada vez (como a versão embedded do java db), achava que ele não servia. Acabei não chegando a testá-lo por conta disso.
Y
YvGa
Sim, ele precisa de um software servidor instalado numa maquina da rede. O seu schema e dados é que ficam num arquivo (.gdb normalmente). Sobre o embedded nao posso falar, nunca usei.
Parece promissor. Preciso testar. Se ele não soltar uma mensagem de erro enquanto um aplicativo atualiza e o outro consulta, tudo bem. Se ele trancar o arquivo e manter os outros processos aguardando para atualizar, melhora a situação, porquê daí não corrompe os dados.
Obrigado!
A
Abdon
Bem em teoria é o que esta especificado, deve funcionar e resolver o seu problema!
D
diego_qmota
Realizei um teste com os bancos: ACCESS, H2 e SQLite. Os que tiveram resultados satisfatórios foram o ACCESS e o SQLite.
O teste consistiu em realizar muitas consultas seguidas, com SELECT, INSERT, UPDATE e DELETE, que manipulavam grandes números de registros - em até 8 estações - mas na verdade, dificilmente o banco será tão “concorrente” assim, porquê mesmo que hajam muitas consultas concorrentes, elas não vão manipular muitos registros.
O teste durava uns 20 minutos…
Minhas conclusões:
O H2 não serve mesmo para compartilhamento em modo embedded. Apresenta muitos…muitos erros quando usado dessa forma.
O SQLite só disparou poucas SQLException de arquivo trancado e o ACCESS também. Mas o SQLite surpreendeu… um banco que parece não ser tão consolidado como outros, suportou um alto nivel de carga de stress e mostrou que só é Lite no nome mesmo…
- brincadeirinha.