[firebase-br] Bando de dados de Imagens

[Jéter Rabelo - GMail]

Bom dia.

Blz, armazena as imagens fora do BD. Faz-se backup do BD e as imagens 
não vem. Dá pau no HD, recupera-se o BD mas e as imagens? Ferrou!

Já fiz das duas formas, e podem ter certeza, armazenar arquvivos dentro 
do banco é de longe a MELHOR solução.

Somente tenha cuidado num select de consulta (com muitas linhas de 
resultado), de não incluir o campo blob no mesmo.

Desculpem meu ponto de vista, mas colocar imagem/XML e etc fora do banco 
é um baita de um POG.

Tenho um BD com 400gb, cujo o qual inclui arquivos de áudio do asterisk. 
Pesquisas instantâneas. Nunca meu cliente reclamou.

Atenciosamente.

Jeter-Jerasoft
______________________
Jéter Rabelo Ferreira
<http://www.jerasoft.com.br>

http://www.jerasoft.com.br
Skype: jeter.rabelo

On 02/06/2015 20:33, Joao Ferreira wrote:
> 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
>>
> ______________________________________________
> 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
>