Tenho um servlet que pega os bytes de uma imagem do banco de dados e, via OutputStream, manda-os para a página que fez a requisição, fazendo com que a imagem apareça. Também funciona normalmente se apontar o servlet como source da tag img.
Porém, esse método não é muito bom vide que, para mostrar uma página dinâmica com a imagem, duas requisições são feitas ao servidor. Portanto se quisesse mostrar uma página com várias imagens vindas do banco, múltiplas requisições seriam necessárias.
Alguém conhece alguma alternativa que não necessite criar arquivos temporários?
nao sei se entendi, mas sempre q vc for mostrar imagens numa pg isso sera feito por multiplas requisicoes… nao tem jeito… se quiser limitar o numero de requisicoes, faz uma imagem só contendo todas, mas nao vejo utilidade nisso…
qual eh o problema de fazer multiplas requisicoes?
_fs
Imagine uma listagem do pessoal cadastrado, mostrando as fotinhos 3x4 deles hehe
50 requisições em 10 segundos = servidor em chamas :mrgreen:
sergiolopes
mas isso eh problema da web… a www eh feita assim mesmo: cada coisa exige uma conexao http…
por exemplo, na pagina de responder topico aqui do guj, pelo q eu contei, ha 28 imagens… fora o html, os css e o javascript… cada coisa eh uma requisicao… e a coisa funciona
_fs
pois é
Uma alternativa seria criar arquivos de imagens temporários, assim poderia criar as tags img apontado para as imagens, criando apenas uma requisição. Mas ficar lidando com isso é uma droga
sergiolopes
eu nao sei os motivos q te levaram a gravar as imagens no banco de dados, mas em geral ninguem faz isso (pelo menos ninguem nunca me deu um motivo q justificasse fazer isso)
qual eh a vantagem de vc guardar no banco de dados se vc nao pode usar esse campo para busca, indexacao e etc? soh pra armazenar? se for só pelo fato de armazenar, use o jeito mais rapido e facil de armazenamento: grave no disco (e coloque o path para a imagem no bd, se for necessario).
isso evita vc tornar seu banco de dados imenso com dados inuteis, deixa o servidor mais rapido, vc nao precisa se preocupar com arquivos temporarios nem cache de imagens na memoria,…
Paulo_Silveira
sergiousp:
qual eh a vantagem de vc guardar no banco de dados se vc nao pode usar esse campo para busca, indexacao e etc?
ops! isso em dia eh possivel com tralhas da oracle.
mas eu ja fiz a burrada de colocar imagens e ARQUIVOS em bd quando nao precisava, apenas pra manter uma portabilidade enorme (bastava copiar o bd)… burrada a menos que voce tenha a necessidade
sergiolopes
serio? nunca ouvi falar… ineteressante algo assim, mas nao tenho a menor ideia de como funcionaria um bd q busque em imagens… “SELECT id FROM table WHERE img LIKE ‘arvore de natal’”??? pesquisa por pixel?
_fs
Decidimos por guardar os arquivos no banco mais por conveniência mesmo.
No sistema, a parte de arquivos é realmente bastante usada. Para terem uma noção, dos 59 mil candidatos cadastrados no banco que estamos trabalhando, 90% tem pelo menos um arquivo de imagem e outro com o currículo, e é possível armazenar qualquer arquivo relacionado a um candidato ou cliente.
Ter esse tanto de pastas ou ficar dependendo de prefixos nos nomes dos arquivos nos pareceu, no mínimo, incômodo. E o arquivo no banco fica apenas alguns pouquissimos kbs maior que o arquivo em disco no windows.
sergiolopes
59 mil imagens numa tabela?!?!?! vc eh louco!!! hehehe
uns 10kb por fotinho 3x4 pelo menos…dá 590 MB de… err… lixo no banco de dados
sinceramente, isso eh loucura total… uma pasta /fotos onde vc coloca /fotos/id.jpg onde id eh o id do cara no banco de dados seria infinitamente mais pratico e melhor
kuchma
Ate onde sei a questao das requisicoes independe do meio de armazenamento. Seja vindo do banco em stream direto, seja vindo do disco de forma “tradicional”, o numero de requisicoes eh a mesma.
Cada tag de imagem, css, javascript, flash, applet, etc, gera uma nova requisicao ao servidor. Portanto (1) escolha onde voce vai guardar as imagens conforme sua necessidade, (2) desencane desse negocio de quantidade de requisicoes e (3) seja feliz.
(se quiser confirmar isso, pegue um pedaco de algum log do apache)
Marcio Kuchma
_fs
sergiousp, esse espaço estaria sendo ocupado de qualquer maneira em disco, não estaria? E o backup também é necessário hehe além de fotinhos 3x4 terem 3-4kbs
E kchuma pensando desta forma você tem razão sim cara, mas há outro problema: fazendo desta forma, também seriam realizadas um monte de conexões ao banco, mesmo que estivesse utilizando arquivos, para pegar os dados da imagem requerida
Valeu pelos replies povo
kuchma
Na verdade nao eh bem um “problema” - eh um requisito do teu negocio. De qualquer jeito vai ao banco - mas voce pode ir uma vez soh trazendo tudo que precisa (se for possivel claro - isso vale para ambos: path ou imagem no banco).
Bom, a solucao default que sempre vemos rolando em foruns e listas de discussao eh: guarde os paths apenas se voce pode fazer isso. Se nao, fazer o que? Guarde os binarios no banco.
Marcio Kuchma
_fs
Mas para guardar os binários em algum objeto estático para todas as requisições futuras pegarem as imagens seria necessária uma senhora gambi hehe mas é com certeza melhor do que fazer quilos de conexão num curto intervalo de tempo.
T
thingol
Bom, minha esposa ajudou a montar o site da Stock Car (que é em ASP, he he he), e ele tem um esquema “híbrido” - o jornalista que monta as matérias manda o html e as figuras para uma página que põe essas figuras na base.
Quando alguém faz uma requisição à página com a notícia recém-criada pelo jornalista, as figuras são obtidas da base e copiadas para a área estática do web site (se for o caso).
Então as figuras têm uns links esquisitos, mas sempre apontando para uma área estática.
Como as notícias são periodicamente atualizadas, volta e meia limpa-se a área estática, e aí se você quer pegar uma notícia “velha” a base é consultada novamente, para recriar a página e as figuras velhas.
kuchma
Acho que saquei. Voce tem que mostrar varias imagens por pagina. Neste caso guardar o path apenas no BD eh muito melhor.
Marcio Kuchma
_fs
Exatamente este o problema kuchma. Mas estamos fugindo disso o máximo possível, pelos motivos que já expliquei nos posts anteriores, e mais um outro: o sistema será distribuído em mais de um servidor.
E thingol, creio que a solução vai ser por aí mesmo, porém com um dinamismo maior no “refresh” dos arquivos gerados.