Há controversias.
Ja vi esta pergunta aqui no forum, muitos gostam de colocar apenas o path no banco e deixar tudo em um local.
O problema que vejo é que as imagens ficam ali expostas, um usuario pode ir la e apagar, e tua app ja vai dar um pau.
Por outro lado o que o pessoal fala sobre guardar no BD, é o espaço de armazenamento, se tu tiver uma quantidade muito grande de fotos pra guardar, pode ser que teu banco se torne um mostrinho.
Se NAO ME engano, na epoca do topico, alguem falou que no Oracle tu consegue deixar as fotos em um local do server e ele gerencia ela, um treco assim.
Então acho que depende muito, se tua app vai ter zilhoes de imagens e do espaço que tu tem disponivel pra aumentar seu BD.
Eu particularmente, gosto de guardar no BD. Mas esta é a minha opnião.
L
lucianomendesprado
É melhor salvar em uma pasta, principalmente se vc estivar trabalhando com varios programadores, pois vai que um deles faça uma consulta por nome de foto usando like, o oracle vai fazer scan em todos os registros com as imagens neles!
verner_a
Eu sugiro uma abordagem diferente. Coloque um Tomcat em um servidor e faça um webservice para fazer o upload e download da foto por um id controlado pelo banco. Assim você não expõem um compartilhamento e tem controle via programa de como armazenar e recuperar as fotos. O id pode ser o nome do arquivo imagem ou qualquer esquema de nomeação que achar interessante implementar. Mesmo sendo uma aplicação de desktop, é fácil fazer um cliente para o webservice.
dyorgio
Eu sou da opnião de colocar pra dentro do banco,
como é uma app Desktop
use o h2 ou hsql (bancos SUPER-EMBARCADOS)
com uma coluna id e uma coluna BLOB.
não entendi porque iria fazer fullsearch…
basta que a coluna id seje uma foreyngkey para a tabela cliente(id)
quem sabe coluna data_cadastro
e descricao tb são boas idéias
T
thingol
“Seje” é dose. De qualquer maneira, só tomar um pouco de cuidado com o HSQLDB, porque ele não é muito bom com arquivos grandes ou com grandes números de linhas, porque ele, em vez de armazenar os dados como uma B-Tree ou uma tabela hash (como os bancos costumam fazer), armazena em uma árvore binária, o que é adequado em memória mas não é bom em disco.
quebrado
Salvar na pasta é muito mais facil! Arquivos no banco se for muito importante mesmo e precisar de um histórico. Web service para isto é usar uma carreta para atravessar a rua. 8)
Andre_Brito
Eu faria de uma ou outra maneira:
Caminho da imagem no servidor ou;
blob.
dyorgio
é o HSQL ja era o H2(www.h2database.org) da de 10 a zero em tudo.
e esse banco suporta milhoes de linhas sem problemas, caso isso SEJE possivel
para sua tabela de imagens.
quebrado
Já usei em site busca de imagem no banco e fica lento. O usuário quer explodir as imagens na tela e não ficar esperando a imagem aparecer. Mas se for uma intranet é outra coisa!
B
Bruno_Laturner
Eu recomendaria armazenar fora do banco, para não sobrecarregá-lo.
Sistema de arquivos clássicos ainda são melhores em armazenar arquivos.
fredferrao
Desktop minha gente, desktop
Uma vez eu comecei a fazer uma app swing pra cartorio, onde a assinatura do cliente era digitalizada e guardada no BD. Na epóca eu fiz em PostGreSQL, rodou de boa, sem travamentos danosos, no maximo um lagzinho de menos de 1 segundo na hora de carregar a foto, nada que um Loading… nao resolva. Isto que na época meu PC era um Pentium IV 1.6, com 512MB RAM, java era 1.5 e sabe se la se meu algoritmo de carregamento da foto era o mais indicado.
Acho que os BDs hoje em dia tem perfeitamente condições pra fazer este trabalho sem afetar a performance, principalmente um oracle da vida.
Juro que nao entendi isso :? É uma tabela normal, onde um campo é do tipo binario(BLOB), neste caso nao existe nome de foto, existe na tabela no maximo o nome do cliente, um like seria entao no nome do cliente, e isto é completamente normal.
E outra, escolher uma tecnologia ou outra, por conta do que possiveis programadores podem fazer com ela???
B
Bruno_Laturner
Só lembre, por favor, na hora que fizerem a consulta na tabela de imagens por qualquer coisa que retorne mais de campo, de retirar o campo BLOB do select da pesquisa. Depois quando forem pegar o arquivo de fato, use somente id do registro.
Se também precisarem do tamanho, nome, e qualquer outro meta-dado do arquivo, coloque-os em outro campo da tabela, e não dentro do BLOB.