Duvida envolvendo "select *" e mostrar esses dados

1. Apesar do Hibernate ajudar muito, acho bastante válido vc aprender a usar JDBC na unha, memso para melhorar seu entendimento sobre como o Java trabalha com bancos de dados
2. Trazer 75000 (ou muito menos que isso) registros do banco é suícidio tanto para o banco quanto para o seu servidor de aplicação. Não é possível, não tem lógica pesquisar todos os registros sem aplicar nenhum filtro. Normalmente vc etá interessado em um Cliente específico, ou em clientes que obedeçam uma determinada condição. Se ainda assim o número de resultados for muito grande, você pode escolher alguma estratégia de paginação. Normalmente vc pode paginar de duas formas (basicamente falando):
   a) Trazer todos os resultados do banco e paginar na aplicação (seu banco sofre e vc usa muita memória do servidor de aplicação)
   b) Trazer somente parte dos resultados do banco e ir buscar o resto quando necessário (o banco nao sofre muito, mas pode criar gargalos na rede caso seu servidor de dados esteja em uma máquina diferente do servidor de aplicações).

Cabe a você analisar qual a melhor solução. Isso varia de caso em caso.

Hummm interessante , mas ha maneira de eu ir pegando o resultado em pedaços ? Desconheco isso hehehe
Só o que conheco eh quando do o executequery ele me retorna todo resultado.

junioma:

Hummm interessante , mas ha maneira de eu ir pegando o resultado em pedaços ? Desconheco isso hehehe
Só o que conheco eh quando do o executequery ele me retorna todo resultado.

Isso será definido não no código Java, mas sim no seu SQL. A sintaxe depende bastante do SGDB adotado, mas em geral você usa LIMIT para isso. Como já é de se imaginar, este comando restringe a quantidade de resultados retornados. Você pode utilizar o LIMIT em conjunto com algum outro recurso específico do banco para se “deslocar” pelos registros do resultado a pesquisa e retornar só aqueles que lhe interessam. No postgresql, por exemplo, você pode fazer algo assim:

select * from usuarios where idade > 18 limit 20, offset 30;

Isso retornaria 20 registros, do 31 ao 50 dentre os encontrados.

Opa!!! Agora saquei!!!
Valew
Uma ultima duvida … vamos supor que tenho uma aplicaçao que possui um formulario de clientes. Em dado momento o usuario deseja buscar por um cliente , entao pressiona um botao de pesquisa … (aqui comessa a duvida) ao clicar nesse botao um novo formulario contendo uma tabelinha é instanciado e nesse novo formulario se enconta o cliente desejava.

Indo um pouco mais a fundo ,qd o usuario clica no botao de pesquisar , digamos que eu instancio esse formulario de busca e entao eu devo passar um atributo no metodo construtor para que esse atributo “receba o valor” que o usuario selecionou no formulario de busca?

Quando eu estava na epoca que programava com as funçoes (em c), qd delegava uma tarefa a uma função , eu poderia esperar um retorno dela … essa ideia em classes desaparece por completo ?

[]s

junioma:

Opa!!! Agora saquei!!!
Valew
Uma ultima duvida … vamos supor que tenho uma aplicaçao que possui um formulario de clientes. Em dado momento o usuario deseja buscar por um cliente , entao pressiona um botao de pesquisa … (aqui comessa a duvida) ao clicar nesse botao um novo formulario contendo uma tabelinha é instanciado e nesse novo formulario se enconta o cliente desejava.

Indo um pouco mais a fundo ,qd o usuario clica no botao de pesquisar , digamos que eu instancio esse formulario de busca e entao eu devo passar um atributo no metodo construtor para que esse atributo “receba o valor” que o usuario selecionou no formulario de busca?

Quando eu estava na epoca que programava com as funçoes (em c), qd delegava uma tarefa a uma função , eu poderia esperar um retorno dela … essa ideia em classes desaparece por completo ?

[]s

Não, essa idéia permanece por completo! Em C chamamos de funções por serem trechos de código soltos, que não têm um dono, mas que fazem algum trabalho: recebem OU não valores como parâmetros e retornam OU não um resultados. No caso de não retornar resultados estamos interessados em seus “efeitos colaterais”.
Em uma linguagem oprientada a objetos estas funções em geral possuem um dono, que é a classe. Assim, as funçòes deixam de serem funções e passam a ser métodos, pois descrevem um comportamento da classe. Mas a idéia de se passar um parâmetro (ou mais de um, ou nenhum) e receber de volta (ou não) um resultado, com certeza permanece!

Na verdade eu acho melhor você se preocupar primeiro com o conceito de orientação a objetos paa depois ver coisas relacionadas a banco de dados. Essa apostila vai te dar uma boa ajuda: http://www.caelum.com.br/caelum/apostila/caelum-java-objetos-fj11.pdf

Você pode tbm dar uma olhada na seção de artigos aqui do guj.

cassio:

1) Apesar do Hibernate ajudar muito, acho bastante válido vc aprender a usar JDBC na unha, memso para melhorar seu entendimento sobre como o Java trabalha com bancos de dados
2) Trazer 75000 (ou muito menos que isso) registros do banco é suícidio tanto para o banco quanto para o seu servidor de aplicação. Não é possível, não tem lógica pesquisar todos os registros sem aplicar nenhum filtro. Normalmente vc etá interessado em um Cliente específico, ou em clientes que obedeçam uma determinada condição. Se ainda assim o número de resultados for muito grande, você pode escolher alguma estratégia de paginação. Normalmente vc pode paginar de duas formas (basicamente falando):
a) Trazer todos os resultados do banco e paginar na aplicação (seu banco sofre e vc usa muita memória do servidor de aplicação)
b) Trazer somente parte dos resultados do banco e ir buscar o resto quando necessário (o banco nao sofre muito, mas pode criar gargalos na rede caso seu servidor de dados esteja em uma máquina diferente do servidor de aplicações).

Cabe a você analisar qual a melhor solução. Isso varia de caso em caso.

Caramba… Então se eu precisar gerar um relatório de inventário, por exemplo, que traz até mais registros que isto é suicídio no Java??? Não posso utilizar paginação, preciso de todos de uma vez para montar o relatório. Como vc faria nesse caso?

marciosantri:

cassio:

1) Apesar do Hibernate ajudar muito, acho bastante válido vc aprender a usar JDBC na unha, memso para melhorar seu entendimento sobre como o Java trabalha com bancos de dados
2) Trazer 75000 (ou muito menos que isso) registros do banco é suícidio tanto para o banco quanto para o seu servidor de aplicação. Não é possível, não tem lógica pesquisar todos os registros sem aplicar nenhum filtro. Normalmente vc etá interessado em um Cliente específico, ou em clientes que obedeçam uma determinada condição. Se ainda assim o número de resultados for muito grande, você pode escolher alguma estratégia de paginação. Normalmente vc pode paginar de duas formas (basicamente falando):
a) Trazer todos os resultados do banco e paginar na aplicação (seu banco sofre e vc usa muita memória do servidor de aplicação)
b) Trazer somente parte dos resultados do banco e ir buscar o resto quando necessário (o banco nao sofre muito, mas pode criar gargalos na rede caso seu servidor de dados esteja em uma máquina diferente do servidor de aplicações).

Cabe a você analisar qual a melhor solução. Isso varia de caso em caso.

Caramba… Então se eu precisar gerar um relatório de inventário, por exemplo, que traz até mais registros que isto é suicídio no Java??? Não posso utilizar paginação, preciso de todos de uma vez para montar o relatório. Como vc faria nesse caso?

Ok, tvz a palavra suicídio tenha sido um pouco forte. Você até poderia trazer todos esses registros, mas concorda comigo que um relatório destes não será gerado toda hora, certo? Entretanto, o tipo de pesquisa que nosso amigo citou irá ocorrer com maior frequência.
Ou melhor, pra que alguém vai querer um relatório destes? Seja impresso, em disco ou que seja, será que alguém realmente olharia uma monstruosidade dessas? 75000 mil itens em um relatório? :shock:
Puxar de uma única vez 75000 registros é problemático com qualquer linguagem, não só com o Java. mas se você for ficar criando objetos a partir destes registros com algum esquema de mapeamento objeto-relacional, com certeza existirá um overhead com essa geração de objetos… No caso de gerar um simples relatório nem concordo com a criação dos objetos, melhor uma simples com os dados, o próprio result set, sei lá… pra que criar objetos se você não vai usá-los?