[OPNIAO] Upload Arquivos

Programação
#1

Saúdo a todos do FORUM,

Estou com uma dúvida, estou fazendo algumas pesquisas e gostaria da opinião de quem já utilizou os dois modelos existentes ao meu ver rsrs…

Questão:

Sobre UPLOAD de arquivos, aonde é melhor armazena-los, no BANCO ou diretamente no HD.
1 - Qual os benefícios e contras entre as duas formas de armazenamento?
2 - Qual das formas tem uma velocidade de leitura melhor?
3 - Qual vocês recomendam utilizar e porque?

Se puderem me ajudar nessa pesquisa agradeço a todos!!
Aguardo

#2

Pesquise nesse forum que encontrará as respostas sobre esse assunto.

#3

Lembrando que esse assunto foi exemplificado pelo Haroldo, não me lembro agora em qual tópico.

#4

Eu procurei e não encontrei oque queria, apenas um tópico com essa mesma pergunta, más a resposta não foi oque eu esperava… Vou continuar a procura, caso alguém queira perder um tempinho respondendo RSRSRS. Ficarei grato.

Obrigado.

#5

Já postei isso a um tempo em outro tópico, não me lembro qual!

Na minha opinião, depende muito do projeto. Pois se você quer armazenar uma grande quantidade de imagens, aconselho utilizar o caminho no banco e guardar a imagem no HD. Com isso você ganha mais desempenho, velocidade. Mas com relação a “Segurança”, “backup” de banco de dados, seria interessante upload direto no banco. Não sou a favor de gravar direto no banco, mas como falei, depende muito do projeto. Se for armazenar apenas uma foto, por exemplo uma logo marca de uma empresa, usa a gravação no banco. Se queres fazer upload de várias fotos de um produto especifico, e você tem vários produtos específicos, utiliza upload no HD e no banco grava apenas o caminho.

Cara,você pode achar mais avaliações no próprio google!

http://forum.imasters.com.br/topic/470126-armazenar-imagens-em-banco-de-dados-ou-diretorios/
http://forum.wmonline.com.br/topic/143097-gravar-caminho-da-imagem-no-banco-de-dados/
http://javafree.uol.com.br/topic-882209-GRAVAR-IMAGEM-OU-CAMINHO-NO-BANCO.html
http://br.answers.yahoo.com/question/index?qid=20081121102038AAjvqrC

#6

Só Armazeno no Banco
Não sei se existe diferença de velocidade, mas em relação à manipulação e segurança - com certeza eu acho melhor.

Forte abraço

#7

Armazenamento de arquivos em banco de dados é algo muito discutido nos fóruns, eu particularmente acho que o desempenho é sim comprometido visto que a maioria dos SGBD´s não são especializados neste tipo de armazenamento não fornecendo por exemplo a opção de compressão dos arquivos armazenados.

Digo que o desempenho fica comprometido e é fácil explicar, todo banco de dados sofre quando o volume de dados armazenados aumenta isso é fato, acontece com banco de dados, computadores, celulares, são mais áreas ocupadas sendo usadas, agora pense uma imagem com resolução baixa tem cerca de 60 - 100 kbytes, agora 1 caracter corresponde a 1 Byte façamos as contas então:

60 Kbytes = 61440 bytes (caracteres)
100 Kbytes = 102400 bytes (caracteres)

Ou seja pra armazenar uma imagem com resolução bem ruim ou pequena você ocupa o espaço correspondente a um cadastro bem feito e completo de uma pessoa com histórico escolar e uma redação de 50 linhas.

A melhor forma de verificar o que estou dizendo seria fazer um sistema e mandar gravar as informações das duas formas em banco diferentes e aí com certeza veríamos que que o banco que armazena as imagens internamente começaria a perder desempenho mais rapidamente, acredito que existam maneiras de otimizar os bancos de dados para este tipo de situação mas acredito que o custo e o trabalho não seriam aplicáveis a um projeto de pequeno ou médio porte.

Complementando existe este banco de dados solução nacional para armazenamento e gestão documental digital.

http://www.softwarepublico.gov.br/ver-comunidade?community_id=3673574

#8

Almeida, temos aqui na empresa um “Sistema de Orçamentos” aonde os documentos e desenhos de engenharia recebidos de clientes ficam vinculados aos seus respectivos orçamentos. Fiz a opção por gravar os arquivos em HD e somente o nome dos arquivos na base para não sobrecarregar o Banco (MySql) e complementei isso com backup’s diarios em outro servidor interno e tb externo. Antes de fazer o multiupload dos arquivos para o HD e gravar o nome na base, faço um tratamento no nome do arquivo tirando espaços em branco, caracteres especiais e acentuação para que na hora de recuperá-los não acuse erro de leitura no link.

Espero ter contribuido com sua pesquisa.

Abraços.

#9

Muito bem,

Fico grato com a opinião de vocês, deu para ter uma base de como farei isso.

Vou fazer alguns testes, oque preciso é assim: Vou armazenar mais ou menos 10 mil PDF`s que não serão feitas alteraçoes, insertes e nem deletes, só será consultado no máximo umas 3 vezes a cada 10 minutos. Vou estar fazendo esse armazenamento inicial no banco para testes, criarei um banco de dados separado do meu más na mesma máquina, farei esse teste inicial usando banco, apenas pela segurança. Caso eu veja que está comprometendo muito o desempenho mudarei para HD local mesmo.

Obrigado a Todos.

#10

Você precisa levar em conta que quando se armazena no banco o php ao tentar recuperar o arquivo precisa grava-lo em algum lugar temporariamente para enviar para o navegador o resultado, assim lembre-se de limpar as pastas temporárias de seu sistema diariamente bem como monitorar o uso do espaço em disco porque uma quantidade assim de arquivos pode facilmente com todos estes acessos estourar seu espaço facilmente.

#11

Blza Saulo, eu iria descobrir isso só quando estourasse rsrsr… Vou fazer isso então.

#12

Diferente de vocês não acho que o tamanho do arquivo ou do banco caia a performance.

Vejam os meus argumentos:

Um SGDB de respeito (MySQL, Oracle, Postgr, MSSQL) não perde o desempenho pelo que está armazenado mas sim pelas requisições, pelo número de conexões simultâneas, pela má construção das queries, pela excessiva normalização, etc… o tamanho de um registro pouco importa uma vez que aí o problema reside na qualidade do hard (do HD)… é problema de leitura e/ou gravação em disco e pouco importa se este registro está em um DB ou em um diretório. Se vocês analisarem a estrutura física de um DB, nada mais é do que uma estrutura de pastas de um OS, cada pasta representa um banco (schema)… a diferença é que essas pastas são lidas pelo DB.

Pelo exposto, nenhum dos argumentos apresentados pelos senhores me convencem da perda de desempenho do DB por conta de um registro ter 5GB ou apenas 5bytes… tudo é uma questão de gravação e leitura no HD, mas não de desempenho do DB.

Podem fazer o teste pra verificar e me digam… até aqui continuo utilizando o banco.

Forte abraço.

#13

Jovito,

O pior é que em BD até o sistema de arquivo criado no HD regula para performance.
Nos meus sistemas em Harbour utilizo sistema de arquivos XFS, porém com o PostGresql utilizo ext3 / ext4, pois são bem mais rápidos.
Armazenar arquivos fora do BD em linux é muito melhor, pois pode-se trabalhar com este arquivo como bem queira, e mesmo assim estará “dentro” de seu sistema, integrado a outras “possibilidades” dentro da organização. Basta criar permissões dos diretórios / pastas conforme a necessidade, sem falar que em linux também poderá utilizar “link’s” simbólicos para estes arquivos, criando muitas maneiras de utilizá-lo, mesmo com toda segurança de um BD.
Hoje não abro mão desta flexibilidade de armazenar arquivos tudo fora do BD.

Att,

Jocimar

#14

jocimar,

Essa é uma decisão que diz respeito às regras do seu negócio…

Ainda continuo afirmando que o tipo de arquivo ou sistema de arquivo não influi no desempenho do banco… isso é uma questão de IO do OS e não da gestão do DB.

Ter o sistema de pastas compartilhadas, senhas de acesso às pastas, etc… são estratégias que você utiliza para ter acesso aos seus arquivos, não quer dizer que na utilização de um sistema tudo fica mais rápido quando o arquivo não está no banco - essa é a discussão.

Forte abraço.

#15

Jovito,

A sua afirmação foi a minha colocação na regra de negócios e possibilidades, como mencionei!
Agora, que no ambiente Unix que o sistema de arquivos utilizado na partição a gravar o BD isto regula sim.
Dê uma olhada nas discussões de PostgreSQL sobre o assunto ! Não esqueça que estou mencionando em Unix/ Linux/Solaris, e não NTFS do windows!

Att,
Jocimar

#16

Jocimar,

Se o DB estiver no Linux é a mesma coisa… até que me prove o contrário, rapidez não é o argumento adequado.

#17

Jovito,

Você encontrará bastante material na lista do PostgreSQL, ou nas listas de BD que necessite para obter provas de cada caso! Eu os obtive no momento em que precisei e tomei decisões.
Em particular utilizo o PostgreSQL, e sei muito bem que o sistema de arquivos ext3 / ext4 são mais rápidos neste BD! foi o que postei!

Não há como discutir os testes que cada um faz, pois a necessidade é particular para cada caso!
Jamais me atrevi em discutir este tipo de assunto, quanto menos ter que provar alguma coisa (qualquer coisa), como estou num fórum, então entendi que seria interessante colocar o que aprendi até o momento!
Estamos aqui para trocar experiências, e no quesito linux / PostgreSQL, este pelo menos sei que diverge do seu, então não há o que se discutir disto!

Att,

Jocimar

#18

Bem Jovito a sua argumentação esbarra exatamente no que mencionei, é obvio que o que fica lento não é o SGBD em sí, e sim o sistema que depende do hardware, o SGBD não tem nada haver com isso, mas é inegável que manter arquivos no banco compromete mais rapidamente o desempenho do seu sistema pois o volume de dados gerenciados pelo banco será maior, isso é óbvio, esses dados estão dentro da tabela do banco mesmo que o banco dependa do sistema de arquivos do SO, e inevitavelmente o SGBD terá que passar por estes dados na recuperação de alguma informação enquanto que se você simplesmente grava um caminho no campo a recuperação dessa informação será mais rápida e ainda não haverá a leitura do arquivo por parte do SGBD quando da recuperação do mesmo pelo php, veja bem INTO OUTFILE diz implicitamente ao mysql “cara pega esse monte de caracter aí nesse campo e me dá um arquivo!!” além de armazenar o mysql precisa ainda converter esses dados.

Vamos lá galera a discussão esta boa!! :slight_smile:

#19

Saulo,

  1. Quem processa IO é o Sistema Operacional e não o DB…
  2. O DB não transforma arquivo nenhum em nada, ele lê os bits na origem e grava no destino…
  3. Quem faz compressão é o Protocolo e não o DB ou IO…

O que vocês têm que entender é que a discussão não passa por ser mais rápido… mas sim por questão de estratégia de negócios, muitos usuários têm dificuldade em tratar com o DB, então colocam a culpa nele.

Forte abraço

#20

Processar IO é uma coisa Jovito, quem se encarrega de pegar os dados binários e devolver ao php ou qualquer outra saída é o mysql, se não fosse assim seria simples fazer um select no campo que contem o arquivo e exibi-lo normalmente sem chamar este comando próprio para arquivos armazenados dentro do banco.

Não falei transformar, tudo é binário em um computador não precisa de transformação, mas precisa ser interpretado, para que a saída saiba o que esta sendo enviado à ela, seja um navegador ou impressora…ou qualquer dispositivo de saída.