Ola
Preciso gravar imagens no banco de dados o problema e o tamanho que isso
vai gerar na minha base.
Andei vendo sobre conversão para base 64 o problema e como fazer ?
alguem tem uma solução?
desde ja agradeço
nao entendi sua divida, nao é so criar um campo do tipo BLOB ?
Qual o banco de dados que você está utilizando?
Os bancos MySQL, PostgreSQL, Oracle, MS SQL Server, DB2 possuem campos BLOB (ou equivalentes) que você pode acessar diretamente pela API JDBC.
Exemplo no PostgreSQL:
File image = new File( filename );
FileInputStream fis = new FileInputStream(image);
ps.setBinaryStream(4, fis, (int) image.length());
No oracle eu tenho este bookmark que já me ajudou uma vez:
http://forum.java.sun.com/thread.jspa?threadID=736236&messageID=4249694
fw
Uma alternativa seria a inclusão do local onde as imagens estão armazenadas em disco no seu banco de dados, uma referência para o caminho em disco.
Abraços,
Alexandre Oliveira
Sim pessoal eu to usando o banco de dados MySql
eu to inserindo as imagens em campo do tipo Blob
o problema e que minha base vai ficar muito pesada
fiz uns testes aqui uma tabela com 150 registros ja estava com
25 mb, acho que muita coisa, ouvi falar sobre imagens convertidas em base 64 que seria so caracteres, tambem num sei se vai resolver o esquema do tamanho da base.
Agradeço desde ja
[quote=andredeividi]Sim pessoal eu to usando o banco de dados MySql
eu to inserindo as imagens em campo do tipo Blob
o problema e que minha base vai ficar muito pesada
fiz uns testes aqui uma tabela com 150 registros ja estava com
25 mb, acho que muita coisa, ouvi falar sobre imagens convertidas em base 64 que seria so caracteres, tambem num sei se vai resolver o esquema do tamanho da base.
Agradeço desde ja[/quote]
André,
o tamanho normalmente não é problema, a questão de performance você consegue resolver seguindo este esquema de modelagem:
Vamos supor que você queira guardar uma foto na tabela pessoa, então ao invés de criar o campo blob direto na tabela pessoa você cria uma tabela pessoafoto com os campos (chave primária de pessoa e o campo blob apenas).
Veja que desta forma você já ganha em performance ao acesso a tabela pessoa e normalmente você irá realizar select em apenas um registro na tabela pessoafoto, enquanto que na tabela pessoa é comum selects com várias linhas.
outro aspecto que você pode verificar se vale a pena para o seu problema, em servidores mysql é utilizar registro compactado.
veja a este link do manual do mysql:
http://dev.mysql.com/doc/refman/4.1/pt/create-table.html
observe este ponto:
[quote]opções_tabela:
TYPE = {BDB | HEAP | ISAM | InnoDB | MERGE | MRG_MYISAM | MYISAM }
| AUTO_INCREMENT = #
| AVG_ROW_LENGTH = #
| CHECKSUM = {0 | 1}
| COMMENT = ‘string’
| MAX_ROWS = #
| MIN_ROWS = #
| PACK_KEYS = {0 | 1 | DEFAULT}
| PASSWORD = ‘string’
| DELAY_KEY_WRITE = {0 | 1}
| ROW_FORMAT = { DEFAULT | DYNAMIC | FIXED | COMPRESSED }[/quote]
veja também estes links:
http://dev.mysql.com/doc/refman/4.1/pt/compressed-format.html
http://dev.mysql.com/doc/refman/4.1/pt/myisam-table-formats.html
fw.
Ps: Trabalho com tabelas no Oracle de documentos que possui mais de 800.000 documentos e uma base física com mais de 130Gb, sem problema nenhum de performance, usando as técnicas acima.
Um conselho: não guarde arquivos no banco. Além de atrelar fortemente sua aplicação a um banco de dados, os bancos não trabalham - tanto internamente quanto externamente - da mesma maneira. Vais ter que caçar nas documentações pelas funções e tipos de campos e terás grandes surpresas quando descobrir que a quantidade de transações, tráfego e processamento para recuperar uma imagem do banco vai de questionável até inaceitável.
O que ainda indico é: grave numa pasta em separado os arquivos e no banco os caminhos. É muito mais econômico recuperar um caminho do que uma imagem.
Até!
Valeu muito obrigado pelo esclarecimento
vou esquecer esse negocio de base 64
Aproveitando o topico
gravar a imagem ta blz mas agora para eu jogar isso na minha aplicação
aplicação desctop.
Gostaria de jogar no icon de um label po exemplo
[quote=maquiavelbona]Um conselho: não guarde arquivos no banco. Além de atrelar fortemente sua aplicação a um banco de dados, os bancos não trabalham - tanto internamente quanto externamente - da mesma maneira. Vais ter que caçar nas documentações pelas funções e tipos de campos e terás grandes surpresas quando descobrir que a quantidade de transações, tráfego e processamento para recuperar uma imagem do banco vai de questionável até inaceitável.
O que ainda indico é: grave numa pasta em separado os arquivos e no banco os caminhos. É muito mais econômico recuperar um caminho do que uma imagem.
Até![/quote]
Eu concordo em partes com estas observações, mas existem outros aspectos a serem considerados, por exemplo:
- Segurança dos arquivos, estando em pastas do S.O. pessoas que possuem acesso ao S.O. mas não tem acesso ao banco de dados podem modificá-las;
- Os arquivos no SO são passiveis de infecção;
- Mudança de acesso ao sistema de arquivo pode inviabilizar ou deixar a aplicação instável;
- Alguns sistemas de arquivos possuem problemas com quantidade de arquivos em uma mesma pasta. O que leva a aplicação gerenciar pastas diferentes;
- Se a aplicação tiver acesso de escrita e leitura no sistema de arquivos ela poderá ser um forma de invasão ou causar danos ao SO hospedeiro.
- Fazer pesquisar por fragmentos de textos em campos blobs é fácil em diversos arquivos do S.O. é muito lento.
Como vocês podem ver, existem prós e contras a utilização. Eu não sei como o MySQL se comporta com bases de dados grandes, mas o Oracle e o PostgreSQL não acarretam grandes modificações nos percentuais de uso de memória e cpu que justifique colocar informações fora da base de dados de um sistema.
Mas este tópico é bastante polêmico.
Avalie com cuidade.
fw
Aqui estamos avaliando todas essa informações
fizemos teste com gravar na base a imagem
e agora estou testando gravar o arquivo no disco e o caminho na base.
Avaliamos
Perfomace e segurança.
Ao gravar a imgem na base ainda que base esta pequena
perfomace esta ok
segurança esta ok
Agora vamos ver com a outra metodologia.
Abraço e agradeço pela ajuda.
Apenas discordando de uma das afirmações do nosso amigo Dieval em que ele afirma que guardar arquivos em disco é inseguro.
Devemos avaliar antes de tudo a segurança que será aplicada ao servidor de armazenamento dos arquivos, pois dependendo do nível de segurança aplicado como backup, diretivas de segurança, antivirus e outros, podemos manter os arquivos em disco sem problemas.
Outro ponto a favor de armazenar em disco seria a facilidade dos servidores de arquivos que podem adicionar performance utilizando técnicas de cache, entre outras. Procure por servidores dedicados de arquivos se for o caso.
Avalie bem, pois não existe uma solução errada e sim a mais adequada ao seu ambiente.
Abraços,
Alexandre Oliveira
[quote=Dieval Guizelini]Eu concordo em partes com estas observações, mas existem outros aspectos a serem considerados, por exemplo:
- Segurança dos arquivos, estando em pastas do S.O. pessoas que possuem acesso ao S.O. mas não tem acesso ao banco de dados podem modificá-las;
- Os arquivos no SO são passiveis de infecção;
[/quote]
Isso é tão questionável do que deixar a permissão por acesso ao banco. Com uma política bem estreita de gerenciamento de arquivos, pode-se ser ( e geramente é ) mais eficiente do que fazer o gerenciamento no DB.
Alguns bancos de dados tem um esforço enorme na hora de trabalhar BLOB apartir de determinados tamanhos por causa do cache e da indexação. Continuo dizendo que uma política de acesso forte é mais eficiente.
Esse pode ser o mesmo problema com SQL Injection, portanto, o problema não é a forma como é feito e sim o conhecimento e experiência de quem projeta e/ou desenvolve.
Recuperar uma imagem já não. Outros exemplos é indexar textos de PDF, XLS, DOC entre outros formatos que não são textos planos. O processamento de trazer o arquivo, mantê-lo na memória, indexá-lo e devolvê-lo é algumas vezes maior do que trabalhar por acesso direto. Banco de dados não são milagrosos para trabalho com arquivos, BLOB não é um tipo simples de se colocar numa árvore de dados e nem um pouco leve em alguns processamentos.
[quote=Dieval Guizelini]
Como vocês podem ver, existem prós e contras a utilização. Eu não sei como o MySQL se comporta com bases de dados grandes, mas o Oracle e o PostgreSQL não acarretam grandes modificações nos percentuais de uso de memória e cpu que justifique colocar informações fora da base de dados de um sistema.
Mas este tópico é bastante polêmico.
Avalie com cuidade.
fw[/quote]
Realmente é polêmico mas forçar esse uso para o DB eu acho ruim.
Até!
Qualquer tipo de arquivo eu guardo no banco de dados.
Tive sérios problemas no passado quando gostariamos de ter nossa infra rodando em Alta-Disponibilidade.
Tivemos que fazer cluster de disco e ficar duplicando todos os documentos.
Sendo que o banco de daos tem várias e várias funcionalidades para resolver esse problema…
[quote=zanatto]Qualquer tipo de arquivo eu guardo no banco de dados.
Tive sérios problemas no passado quando gostariamos de ter nossa infra rodando em Alta-Disponibilidade.
Tivemos que fazer cluster de disco e ficar duplicando todos os documentos.
Sendo que o banco de daos tem várias e várias funcionalidades para resolver esse problema…[/quote]
Política de backup e “mirroring” são possíveis tanto em disco quanto em banco. Para sistemas também tem várias e várias ferramentas e funcionalidades para isso.
Que raios de “mirroring” é esse seu sem precisar de um segundo disco pelo menos?
Até!
[quote=maquiavelbona][quote=zanatto]Qualquer tipo de arquivo eu guardo no banco de dados.
Tive sérios problemas no passado quando gostariamos de ter nossa infra rodando em Alta-Disponibilidade.
Tivemos que fazer cluster de disco e ficar duplicando todos os documentos.
Sendo que o banco de daos tem várias e várias funcionalidades para resolver esse problema…[/quote]
Política de backup e “mirroring” são possíveis tanto em disco quanto em banco. Para sistemas também tem várias e várias ferramentas e funcionalidades para isso.
Que raios de “mirroring” é esse seu sem precisar de um segundo disco pelo menos?
Até![/quote]
Onde eu falei que só utilizava 1 disco???
Já existe solução pra tudo quando se fala de Alta-Disponibilidade e Armazenamento.
Oracle ASM faz algumas dessas coisas em conjunto com soluções da EMC. Dae fica bala!
Só quero dizer que colocar arquivos em banco de dados hoje já pode ser uma boa solução.
Ou melhor… Em um ambiente corporativo. $$!
Não sei se já falaram aqui sobre indexação de documentos.
Mas é outro ponto favoravel quando se usa banco de dados.
Tem um exemplo legal no site tec da Oracle sobre isso:
Oracle Text
A única grande vantagem que eu vejo no uso de file system é que não tem nenhum tipo de processamento pesado para se mostrar o documento.
O acesso é totalmente direto.
Talvez por esse motivo, que só se vale a pena ter as imagens do layout do site em filesystem!
[quote=zanatto]Não sei se já falaram aqui sobre indexação de documentos.
Mas é outro ponto favoravel quando se usa banco de dados.
Tem um exemplo legal no site tec da Oracle sobre isso:
Oracle Text
A única grande vantagem que eu vejo no uso de file system é que não tem nenhum tipo de processamento pesado para se mostrar o documento.
O acesso é totalmente direto.
Talvez por esse motivo, que só se vale a pena ter as imagens do layout do site em filesystem![/quote]
Nós aqui testamos o Oracle Text no Oracle 10g, e tivemos alguns pontos contra:
- se o arquivo tiver uns 300MB, a indexação começa a consumir muito processamento e os índices não ficam legais;
-quando bate a casa de uns 50.000 arquivos ( alguns milhões de índices ), a indexação fica muito, mas muito lenta, deixando você com muita raiva.
Mas para fazer uma busca, fica realmente muito rápido, mas como nos sistemas daqui temos que ter alguma liberdade de indexação e uma carga relativamente grande para a infraestrutura, o Oracle Text ficou para outra vez.
Até!
Qual foi a solução que vocês usaram?
[quote=maquiavelbona][quote=zanatto]Não sei se já falaram aqui sobre indexação de documentos.
Mas é outro ponto favoravel quando se usa banco de dados.
Tem um exemplo legal no site tec da Oracle sobre isso:
Oracle Text
A única grande vantagem que eu vejo no uso de file system é que não tem nenhum tipo de processamento pesado para se mostrar o documento.
O acesso é totalmente direto.
Talvez por esse motivo, que só se vale a pena ter as imagens do layout do site em filesystem![/quote]
Nós aqui testamos o Oracle Text no Oracle 10g, e tivemos alguns pontos contra:
- se o arquivo tiver uns 300MB, a indexação começa a consumir muito processamento e os índices não ficam legais;
-quando bate a casa de uns 50.000 arquivos ( alguns milhões de índices ), a indexação fica muito, mas muito lenta, deixando você com muita raiva.
Mas para fazer uma busca, fica realmente muito rápido, mas como nos sistemas daqui temos que ter alguma liberdade de indexação e uma carga relativamente grande para a infraestrutura, o Oracle Text ficou para outra vez.
Até![/quote]
Para os índices: http://lucene.apache.org/java/docs/index.html
Customizamos parte da indexação - deixando a maior parte incremental -, acabamos ganhando em espaço de armazenamento e velocidade da criação dos índices, mas perdemos alguma performance - nada desesperador - em buscas.
E deixando no filesystem, foi mais “simples” garantir a integridade e backup dos arquivos - ninguém merece pdf com mais de 250MB.
Até!