Qual o banco de dados mais utilizado para esse tipo de aplicativo ???
Olá
Todos podem ser usados. A recomendação é que não rode exclusivamente na mesma máquina que a aplicação desktop. Se for para fazer programas com o banco de dados exclusivamente na mesma máquina use VB ou Clipper
[]s
Luca
[quote=Luca]Olá
Todos podem ser usados. A recomendação é que não rode exclusivamente na mesma máquina que a aplicação desktop. Se for para fazer programas com o banco de dados exclusivamente na mesma máquina use VB ou Clipper
[]s
Luca[/quote]
obrigado
mais em aplicacaoes desktop para rodar na msm maquina? qual banco que é mais utilizado ???
Amigo utilize o postgre ele atende
aplicacoes de pequeno medio e grande porte.E muito bom
e facil de usar
Não conheço o postgree mas tenho testado o MySql e esta me atendendo muito bem…
Criei um aplicação para teste usando um banco na mesma máquina e acessando um banco em outra máquina nos dos casos foi muito bem.
Estou criando um banco com tabelas com 1M de registros pra testes, quero ver como ele se sai.
Luca
Não entendi porque você que se fosse pra usar um banco exclusivo e na mesma maquina pra usar Clipper ou VB… que diferença faria ? Porque não poderia usar Java ?
E até onde sei existem o que não faltam são aplicações em VB acessando bancos remotamente… como client/server.
Um abraço a todos.
Olá
Sim, é verdade. Existem aplicações em VB client/server.
Mas é exatamente por client/server ser coisa do milênio passado, disse para não usar Java. Com Java tanto faz o banco de dados estar na sala ou lado ao na Conchinchina. Fazer uma aplicação para acessar o BD exclusivamente na própria máquina ou confinado na rede local é uma bobagem contra a qual venho lutando desde 2001 e ainda tem gente que teima em fazer isto com Java.
Meu conselho neste caso: Use Clipper, FoxPro ou VB. Vai dar menos trabalho e funcionará melhor.
Use Java quando quiser alguma coisa que sirva neste milênio com todo mundo conectado.
[]s
Luca
Ola Lucca,
Infelizmente para fins de estudos estou desenvolvendo uma aplicação desktop com acesso a BD remoto num esquema client/server…
Nesse caso qual modelo você aconselharia ?
Considerando que a aplicação não é Web.
[]s
Olá
Meu conselho? Que não faça isto nem como fim de estudo.
Se ainda não aprendeu servlet, nem mexa com banco de dados. Estude outras coisas importantes do Java como collections, threads e sockets. Procure exemplos na web para estudar.
Depois que que aprender servlets e HTTP, tente acessar o banco de dados via http usando classes como URLConnection.
MUITO IMPORTANTE!
Se é para fim de estudo, estude logo como usar o JUnit e desenvolver orientado a testes. Veja minha assinatura. Entre no blog do Guilherme Chapiewski, baixe os slides da apresentação dele sobre TDD e veja os links. Um dia você me agradecerá este conselho.
[]s
Luca
[quote=Luca]Olá
[quote=Zeed01]
FoxPro
[]s
Luca[/quote][/quote]
FoxPro funciona bem tb para pontos bastante remotos, pelo menos até onde vi. Apesar de seus paus doidos, é possível usar O.O, porém não tão bem qt java.
Marck.
po bom topico… assim pelo que conseguir entender… e o que Luca falou… nao é recomendavel… fazer um programa para desktop e o BD rodar na mesma maquina? como acontece em outras linguaguens? como delphi, VB? eu teria que montar outra maquina para rodar o BD e a maquina do cliente… conectaria a ele? pensei que isso seria somente essencial… com web… mas desktop recomenda isso?
Recomendo o uso do HSQLDB. Se você quiser usar uma solução que permita trabalhar de forma simples nesse deployment e permita evoluir para uma arquitetura com servidor Java EE no backend, use o genesis
Na medida do possível sim, mas e se seu aplicativo for “desconectado”?
ai vc tbm pode se perguntar, pq faria hoje uma aplicação “desconectada”?
minha resposta pessoal, pq o Brasil ainda é desconectado, mas o nicho “conectado” é muito grande já.
FIREBIRD 2.x 
[quote=LPJava]po bom topico… assim pelo que conseguir entender… e o que Luca falou… nao é recomendavel… fazer um programa para desktop e o BD rodar na mesma maquina? como acontece em outras linguaguens? como delphi, VB? eu teria que montar outra maquina para rodar o BD e a maquina do cliente… conectaria a ele? pensei que isso seria somente essencial… com web… mas desktop recomenda isso?
[/quote]
Pelo que entendi do Luca, não é que o Delphi, VB e cia trabalhem só dessa maneira; é que pra estas finalidades mais simples (não voltadas para Internet) são mais eficientes. E que o ponto onde Java faz a diferença não será estudado ou utilizado.
E, mesmo trabalhando com Delphi, não recomendo de jeito nenhum misturar qualquer tipo de aplicação com um servidor de banco de dados, seja ela desktop, midleware, web, servidor de e-mail, servidor de internet, servidor de câmeras (já teve um gerente de cpd cliente nosso que jurava que isso não tinha problema), etc.
Olá
[quote=marciosantri]Pelo que entendi do Luca, não é que o Delphi, VB e cia trabalhem só dessa maneira; é que pra estas finalidades mais simples (não voltadas para Internet) são mais eficientes. E que o ponto onde Java faz a diferença não será estudado ou utilizado.
E, mesmo trabalhando com Delphi, não recomendo de jeito nenhum misturar qualquer tipo de aplicação com um servidor de banco de dados, seja ela desktop, midleware, web, servidor de e-mail, servidor de internet, servidor de câmeras (já teve um gerente de cpd cliente nosso que jurava que isso não tinha problema), etc.[/quote]
Exatamente. Obrigado por traduzir o que eu disse e que talvez não tenha ficado claro.
A turma precisa lembrar em qual ano nós estamos. Até 2001, a arquitetura com tudo confinado na rede local era a última Coca-Cola do deserto. Hoje cheira mal em qualquer parte do mundo, mesmo na minha casa em Paraty, no meio da mata atlântica, só com acesso à Internet discada.
[]s
Luca
[quote=Luca]Olá
[quote=marciosantri]Pelo que entendi do Luca, não é que o Delphi, VB e cia trabalhem só dessa maneira; é que pra estas finalidades mais simples (não voltadas para Internet) são mais eficientes. E que o ponto onde Java faz a diferença não será estudado ou utilizado.
E, mesmo trabalhando com Delphi, não recomendo de jeito nenhum misturar qualquer tipo de aplicação com um servidor de banco de dados, seja ela desktop, midleware, web, servidor de e-mail, servidor de internet, servidor de câmeras (já teve um gerente de cpd cliente nosso que jurava que isso não tinha problema), etc.[/quote]
Exatamente. Obrigado por traduzir o que eu disse e que talvez não tenha ficado claro.
A turma precisa lembrar em qual ano nós estamos. Até 2001, a arquitetura com tudo confinado na rede local era a última Coca-Cola do deserto. Hoje cheira mal em qualquer parte do mundo, mesmo na minha casa em Paraty, no meio da mata atlântica, só com acesso à Internet discada.[/quote]
Luca, não vou entrar no mérito da questão - se isso deve ou não acontecer, se é bom ou mal. Mas o fato é que ainda teremos aplicativos desse gênero, novinhos em folha, por um bom tempo. A própria Sun estimula esse tipo de arquitetura.
Quer um exemplo? Dentre os novíssimos componentes SwingX, estão o JXLoginPanel e JXLoginDialog. E entre as classes envolvidas nesse processo está a JDBCLoginService que, como o nome já dá a entender, autentica um usuário se ele/ela conseguir se conectar ao banco de dados.
Também é possível utilizar JAAS para embasar o mecanismo de autenticação/autorização do software, que é flexível o suficiente para outras arquiteturas.
Olá
Exato. E pior: a Sun teima em chamar estes programinhas de aplicação desktop.
E estão trabalhando em componentes como aqueles antigos do Delphi que acessam banco de dados diretamente da tela.
A Sun continua gastando energia onde não deve. Se querem incentivar aplicações desktop competitivas, deveriam se concentrar em melhorar a API de impressão e a de conexão com dispositivos, onde o Java ainda continua perdendo de goleada para os concorrentes como o C# por exemplo.
Como eu estou cansado de dizer por aqui há muitos anos, Firefox, Firebird, Netbeans, Eclipse, Adobe Reader são aplicações desktop. E todos eles se conectam com a Internet.
Eu acho que se eu fosse desenvolver algo como um tocador de mp3, faria com que se conectasse à internet para baixar músicas. Mas se rodasse isolado como o Windows Media Player, jamais faria em Java.
E agenda sem que eu possa acessá-la de qualquer parte do mundo é pior do que meu celular. Justo agenda os “professores” dão como tarefa para os alunos fazerem programinhas Java desconectados.
[]s
Luca
Mas tem o lado bom, Luca.
O que o Michel disse é bem possível, e ainda podemos utilizar o HSQLDB ou o Derby/JavaDB para armazenar dados locais e trabalhar em cima deles off-line.
Se fizer o "dever de casa" direito, um software pode começar como
- cliente -> servidor de banco de dados
e evoluir para - cliente -> middleware -> backend.
Um exemplo de como isso pode ser útil (senta que lá vem históra):
Suponha que um micro-empresário possui quatro lojas espalhada por três cidades diferentes. Ele não tem um software que apóie o seu negócio - ou tem alguma coisa que não o faz direito - então é preciso percorrer todos os dias as 4 lojas, não necessariamente sozinho, para administrar o andar da carruagem.
Poderíamos ter um repositório central, um servidor de aplicativos que lida com esse banco de dados e diversos rich clients que acessam os componentes de negócio nesse middleware.
São diversos tipos de cliente: para ponto-de-venda, administração. Esse último, utilizado pelo empresário para acompanhar o estado global de seu empreendimento, em sua própria casa. (Imagine-se aí em Parati acompanhando vendas, custos, etc. numa loja no Rio, outras 2 em Sampa, outra no ABC. 8) ).
Mas é claro que isso tem um custo, e dificilmente esse empresário vai perceber que vale a pena. Então, como alternativa, pode ser sugerido a arquitetura 1 e direcionar esforços de venda para entregar ao cliente um software com a arquitetura 2.
Daí pra frente, quem sabe o software não se conecta com outros sistemas de informação, possivelmente de fornecedores. Dá até pra "empurrar" uma loja virtual…
Bem, se você estiver se referindo ao Beans Binding (JSR-295), eu não vejo isso dessa forma. Aliás, quando penso em bindings para Swing, como o do Genesis e do JGoodies, nem passa pela minha cabeça banco de dados e acredito que seja assim com a maioria dos desenvolvedores Swing.
A missão aqui é eliminar os maledetos métodos fireAlgumaCoisaMudou para amarrar dois widgets, como uma combobox e uma tabela, uma lista e um campo de texto. Usar observer pra isso é no mínimo massante.
[editado] Entenda eliminar no contexto do desenvolvedor. Eles estarão lá, mas não teremos mais que lidar com eles. [/editado]
Já o Databuffer é outra história e está relacionado com o que você está dizendo.
Até onde sei, esse projeto existe para aplicativos stand-alone, e não sistemas de informação. Se vão usar para isso (e vão), é outra história…