JavaDB

Olá Pessoal,

 Antes de mais nada, é um prazer fazer parte de um grupo de discussão sério como é o GUJ. Minha expectativa, acredito, é a mesma de vários colegas que almejam conhecer cada vez mais a linguagem Java. Espero contar com o apoio dos colegas deste grupo.

  Sou iniciante em Java e atualmente sou especialista em sistemas desenvolvidos na linguagem ACCESS da microsoft.

  Vamos a minha questão: pretendo utilizar o banco de dados JavaDB e o NetBeans como padrão para começar a desenvolver meus [b]aplicativos 
                                       multiusuario[/b] Desktop e para Web. 
                                       Pergunto aos colegas, este banco é confiável ?   suporta vários usuários conectados ao mesmo tempo ?  Qual a capacidade máxima dele?

Um abraço

Link

Olá ,
Procure sobre o Derby DB.
http://developers.sun.com/javadb/
http://www.java-tips.org/blog/
http://db.apache.org/derby/docs/dev/pt_BR/getstart/cgsinsta.html
http://db.apache.org/derby/papers/DerbyTut/index.html
http://wiki.apache.org/db-derby/WorkingWithDerby
http://www.guj.com.br/posts/list/79888.java

sds.

boa tarde William, muito obrigado por responder a minha questão.

Acabei de olhar os links que vc me enviou e cheguei a uma conclusão: vou usar o JavaDB, pelo que eu li, ele é um banco de dados relacional como um outro qualquer e com uma vantagem sobre os outros; é desenvolvido em Java puro é pode ser embebido (embedded database) dentro do meu projeto.

A dúvida que ainda persiste é que se posso também utiliza-lo para aplicativo WEB e se a performance será boa ?

E você, qual banco de dados adotou ?

Um abraço

Link

[quote]Link Wrote…: A dúvida que ainda persiste é que se posso também utiliza-lo para aplicativo WEB e se a performance será boa ?[/quote] Olá não uso muito o JavaDB/Derby Database, mais pelo que li ele muito legal, acredito que se vc. vai desenvolver um CRUD ele irá servir e muito pois para que usa MS-ACCESS ele é um BMW X3.
Estude o Derby no modo Network e no modo Embedded.

[quote] A dúvida que ainda persiste é que se posso também utiliza-lo para aplicativo WEB e se a performance será boa ? [/quote]Apesar de ser um peso leve e, pelo que lí de autores “sérios” ele é um nanico feito em java que pode levar a nocaute alguns bancos mais famosos.Não sei qual o seu score em java mais nunca pense em criar seus projetos voltados para o banco de dados pense sempre em “Domain Model”, se for usar Web em duas camadas use JSTL e nunca use scriptles, JDBC use do tipo 4 e sejá feliz.
É isso ai bons códigos.
sds.

Muito esclarecedor !!

Valeu mesmo William.

Um abraço

Link

Link,

Não deixe de considerar também o HSQLDB, outro BD puro-Java muito bom…

Link,

não quero criar um flame, mas com relação a banco de dados para web a primeira questão a ser considerada é quais recursos o seu provedor permite utilizar. A maioria permite o MySQL, SQL Server e PostgreSQL. Não conheço nenhum que utilize o JavaDB.

Também em relação ao provedor é importante observar que:

  1. Maquina dedicada ou maquina virtual dedicada - nenhum problema.
  2. Máquina não dedicada - verificar se a VM será exclusiva sua, caso isso não ocorra, é mais do que recomendável não utilizar banco de dados puro java, tais como JavaDB (Derby), HSQLDB, H2 etc.

com relação a performance existe vários benchmarks no mercado e cada qual puxa a sardinha para o seu lado, mas tem alguns links que você pode levar em consideração:

Comparações feita MySQL AB com outros SGBD:
http://dev.mysql.com/tech-resources/crash-me.php

H2, na página inicial existe um comparativo de performance:
http://www.h2database.com/

O HSQLDB é um dos mais utilizados atualmente, é mantido pelo grupo do JBoss e foi a ferramenta escolhida pelo grupo do OpenOffice para embutir na suite.

Acho que cabe observar que o H2 foi feito pelo criador do HSQLDB e está (na minha opinião) mais maduro, eu fiquei sabendo dele mais recentemente e estou fazendo vários testes, ele é simplesmente fantástico, em apenas um jar de 1.143Kb tem tudo. E, utiliza o ODBC do postgresql o que facilita para migração de aplicações legadas (MS).

Outra técnica muito boa do H2 chama-se linked table que permite criar uma tabela virtual que na realidade está em outro banco de dados (equivalente a tabela vinculada do Access), veja um exemplo:

CREATE LINKED TABLE test_link('com.mysql.jdbc.Driver', 'jdbc:mysql://localhost/test', 'sa', 'sa', 'TEST'); select * from test_link;

Para aplicações embarcadas, ou em três camadas (para LANs ou WANs), os bancos puro java são bons. Para aplicações web, eu não tenho nenhuma experiência de uso real (em função do citado acima - problemas com os provedores).

A maior parte das aplicações web que trabalho são em Oracle, um pouco por causa de tradição, um pouco por causa de contratos (depois que você comprou a licença da Oracle, mantê-la a um custo de 7% ou 15% é muito mais fácil que migrar aplicações).

No javadb, uma coisa que não me agrada é o parse (ele é feito com o javacc), ele é mais pesado que os dos concorrentes (puro java), tanto em consumo de memória quanto a tempo de processamento.

Outro aspecto que considero relevante:
Eu já vi e participei de equipe que perderam dados em bancos:

  • Sybase
  • SQL Server
  • Informix
  • Progress
  • MySQL
  • PostgreSQL e
  • Oracle

De todos os incidentes, os casos com Oracle sempre foram causados por falhas humanas, não que o Oracle não tenha problema, mas é muito mais fácil recuperar uma base de dados Oracle quando você segue o manual do que com os outros SGBDs.

Pessoalmente, quando o projeto não tem problemas de recursos financeiros, para escolha de hardware e banco, a minha escolha é Oracle. Mas veja o que eu disse, recursos para o banco e hardware, a gente normalmente consegue melhores custos/beneficios com os concorrentes, apesar de não ter os mesmos recursos, segurança etc.

Eu não sei a confiabilidade do cluster do MySQL, mas o recurso RAC ou mesmo o GRID da Oracle são muito bons.

Para aplicações menores eu estou utilizando:

  • Inscrições para cursos, sistemas web da Escola Técnica da UFPR, comprovantes de matrículas e etc os bancos MySQL.
  • Para o banco do moodle, utilizamos o Postgresql.
  • Para o sistema de workflow de processos utilizamos o Oracle.
  • No Núcleo de Concursos da UFPR, utiliza-se o Oracle a mais de 15 anos.

Com relação ao HSQLDB recomendo o uso com muito cuidado, ele é rápido e simples, mas tem que ser muito bem configurado para não perder informações, os modos defaults dele são para situações ideais em que não ocorrem falhas de luz, usuários descuidados etc.

qualquer dúvida pergunte aí e tentamos ajudá-lo.

até mais,

Dieval

[quote]Dieval Guizelini Wrote…: Pessoalmente, quando o projeto não tem problemas de recursos financeiros, para escolha de hardware e banco, a minha escolha é Oracle. Mas veja o que eu disse, recursos para o banco e hardware, a gente normalmente consegue melhores custos/beneficios com os concorrentes, apesar de não ter os mesmos recursos, segurança etc.
[/quote] Se avaliar custos/beneficios o Oracle é um ótimo (= melhor) banco “corporativo” e há um bom concorrente não muito famoso por aqui que é o DB2, dos livres fico com o PostgreSQL.

Bom dia a todos. Que a semana de voces seja otima!

Dieval Guizelini, quero lhe agradecer pela aula que nos deu sobre a utilização de Banco de dados. Assim como o William, estas informações que me deram serão de grande utilidade pra mim, já que sou iniciante no Java e pretendo adota-lo como linguagem de desenvolvimento.

Dieval, se eu quiser montar uma intranet dentro da empresa para adotar o JavaDB e assim ficar livre de hospedagem em provedoras, quais são as ações que devo fazer ?

Um abraço

Bom vou falar um pouco sobre a experiência que obtive utilizando base de dados JavaDB

Acho que o ponto atrativo principal do JavaDB é a possibilidade de embarcar o SGBD em qualquer aplicação java sem a necessidade de ter de dispor driver (o driver para o derby é nativo) nem a necessidade em se manter um 3rd party software no esquema arquitetural de uma aplicação.

Vulgarmente falando em termos de implantação ele é “a mão na roda” para desenvolvimento de aplicações leves, que embora necessitem de um sgbd.

A documentação aborda questões sobre controle de ruptura, transações e outras questões fortemente presentes em bancos maiores, porém acredito eu que se fosse o caso de fazer-se a necessidade de utilizar um sgbd para forte controle transacional o foco neste caso seria “corporativo” e talvez o derby não encaixasse nestes requisitos.

Acho que talvez o derby é muito mais recomendado para ser utilizado no modo embarcado, pois pelo que vi e utilizei, o grande diferencial dele estaria nesta premissa

Mas a grosso modo achei que é um banco rápido, eficiente e leve… vc embarca ele na tua aplicação com apenas 2,6mb e teu aplicativo fica completamente transparente quanto a utilização ou não de um sgbd…
Claro que talvez se formos comparar questões ténicas talvez ele perca, mas acredito que ele em si não foi desenvolvido com objetivo de superar em desempenho e segurança os já existentes, mas sim trazer uma nova proposta de utilização…
Principalmente nos tempos de hj em que clouding virou moda e até padaria quer ter website…

Tópico movido para o fórum de persistência.

JavaDB já vem com a instalação padrão do Java 6.

[quote=Dieval Guizelini]Link,

não quero criar um flame, mas com relação a banco de dados para web a primeira questão a ser considerada é quais recursos o seu provedor permite utilizar. A maioria permite o MySQL, SQL Server e PostgreSQL. Não conheço nenhum que utilize o JavaDB.

Dieval[/quote]

Seguinte… para utilizar o derby embarcado a única coisa que o host precisa disponibilizar é a maquina virtual, o derby neste caso fará parte da aplicação java e (observe arquitetura) as transações e conexões seriam delegadas diretamente ao servlet-container ou servidor de aplicação … não confunda os conceitos de rede com o modo embarcado do derby, aonde não existe um servidor de rede para o banco…

Caso a arquitetura fosse em modo Networking o derby rodaria como um sgbd comum, sendo um serviço a parte aonde a aplicação acessaria a base atraves de um protocolo de rede… Não é o caso para o derby embarcado

Talvez utilizar o derby no modo “comum” de sgbd não seja realmente boa escolha, haja visto que temos bancos livres que estão maturando seu código a alguns anos e conseguem em alguns casos concorrer frente a frente com sgbd’s comerciais pagos…

Porém se você tem um proposta de aplicativo e pretende “literalmente” embarcar o banco em sua aplicação afim de reduzir possíveis gargalos vindos de ferramentas externas, o derby/javaDB seria uma boa

Eu ja li toda a documentação do derby/javaDB e atualmente estou utilizando-o em um projeto web comercial de pequeno/médio porte. E pelo menos até então, estou satisfeito com os resultados obtidos utilizando este sgbd.

Acho que performance é algo realmente discutível em vários cenários… 99% dos desenvolvedores gostam de sair levantando bandeiras sobre tecnologias preferíveis… geralmente estes, o fazem por incompetência ou relutância em aprender tecnologias diferentes as quais trabalham no momento (preguiça, resumidamente falando)…

Ja vivenciei casos em que o desenvolvedor utiliza oracle apenas para expor o uso da marca oracle em seu “sisteminha” que não necessariamente necessitava de questões escalares para justificar o uso de uma ferramenta tão completa.
E se essa “necessidade” realmente for vir a nível de: “diferencial”, com a API do JNDI presente, é ridiculamente simples migrar uma plataforma desenvolvida em derby para mysql e inclusive oracle db2 que compartilham das mesmas sintaxes e recursos

espero ter ajudado