[firebase-br] Bando de dados de Imagens

Joao Ferreira jfsferreira em gmail.com
Ter Jun 2 20:33:57 -03 2015


Viva....

Para começar devo dizer que esqueça guardar fisicamente as imagens no BD.
Isso não só consome muito espaço precioso do Banco de Dados como torna o
seu uso muito complicado.
Gere para cada imagem uma UUID (
http://en.wikipedia.org/wiki/Universally_unique_identifier) e atribua essa
UUID ao nome da foto, guardando na BD apenas a UUID e path para a imagem
além de outras informações uteis sobre a imagem que ache necessário.

No dia 2 de junho de 2015 às 15:12, Gladiston Santana <gladiston em vidy.com.br
> escreveu:

> Não faz muita diferença o tamanho do arquivo de dados, não deveria se
> preocupar com isso. milhares registros com ou sem BLOBS gigantes terá o
> mesmo tempo de pesquisa, o que muda é o tempo de resgate do conteúdo quando
> o BLOB for requisitado. Então evite situações de select * from. Em meus
> programas blobs só são resgatados quando recebem o foco ou a guia onde for
> exibido o objeto tiver que ser exibida. Tenho sistemas que guardam
> doc/xls/png que funciona harmoniosamente desde quando o FB 1.5 foi lançado.
> No site firebase e na internet existem estatísticas que desmistificam a
> idéia de que tamanho importa.
> Imagina que seus binários fossem guardados fora do banco, não ocuparia o
> mesmo espaço, mas noutro lugar? E se tivesse de ler um arquivo no disco,
> não leria o mesmo tamanho?
> O que torna melhor guardar dentro do banco de dados é a segurança contra o
> acesso externo que se dará por meio dum programa e não um explorer do
> windows, também economiza espaço, pois NTFS tem página de 4k e disperdiça
> muito espaço para armazenar imagens e também a capacidade de lidar com os
> mesmos diretamente pelo programa que você criou, por exemplo, quando alguém
> baixa um PDF, poderá assiná-lo ou incorporar um texto na vertical
> "CONFIDENCIAL", enfim tudo que puder fazer com o arquivo através do
> programa não dependerá de terceiros.
> O que atrapalha na digitalização com o Firebird é que o mesmo ainda não
> possui busca textual e isso seria uma mão na roda com PDF/A. Até existe
> ferramentas de terceiros como o IBO que é capaz de introduzir buscas
> textuais, mas não é um recurso nativo  do FB.
> Página de dados e os BLOBs no FB são guardados de maneira diferenciada,
> então os engenheiros pensaram na melhor forma de armazená-los que
> beneficiasse os programas.
> O que você pode fazer para melhorar a performance já que de antemão vocÊ
> sabe que ele será grande é criar um database de tamanho enorme e mudar
> autogrowing para algo gigante também, isso evitará a fragmentação do
> arquivo de dados no disco. Talvez possa até desligar o autogrowing e
> definir uma mega tamanho razoável para guardar imagens por muitos anos.
> O campo segment size é um mero informativo, ele não tem objetividade para
> os dias de hoje,se ele estiver te confundindo ignore-o.
>
> []´s e boa sorte.
>
> Em 1 de junho de 2015 10:54, Fábio P. Santos <fpsgyn em gmail.com> escreveu:
>
> > Estou como um projeto para guardar documentos digitalizados, considerando
> > na faixa média de 50.000 por mês. Atualmente utilizo o Fireibrd 2.5.4.
> >
> > Na tabela que irá guardar os dados digitalizados existe um campo do tipo:
> >
> > BLOB SUB_TYPE 0 SEGMENT SIZE 16384
> >
> > Será que com este volume de informações as transações e consultas não
> > ficaram muito lentas ?
> ______________________________________________
> FireBase-BR (www.firebase.com.br) - Hospedado em www.locador.com.br
> Para saber como gerenciar/excluir seu cadastro na lista, use:
> http://www.firebase.com.br/fb/artigo.php?id=1107
> Para consultar mensagens antigas: http://firebase.com.br/pesquisa
>



Mais detalhes sobre a lista de discussão lista