Ir para o conteúdo
  • Revista PROGRAMAR: Já está disponível a edição #60 da revista programar. Faz já o download aqui!

bioshock

Store images BD or Folder? (Resolvido)

Mensagens Recomendadas

bioshock

Tenho me deparado com esta dúvida, o que preferem? Guardar as imagens, quando fazem o upload,  numa pasta à parte e apenas o nome da imagem na BD, ou preferem guardar tudo na BD?

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
softklin

Eu prefiro guardar imagens em ficheiros porque:

- Os bits de uma imagem não são informação pesquisável

- Enchem a base de dados com "lixo" (consequência do ponto anterior)

- Aumenta o tráfego SQL e consequentemente pode atrasar outras operações

Dessa forma deixas para o sistema de ficheiros a tarefa de gerir as imagens (por exemplo, pode ser útil numa situação de cópia para outra pasta, sem recurso a scripts que acedam ao servidor SQL e extraiam de lá a imagem).


Nick antigo: softclean | Tens um projeto? | Wiki P@P

Ajuda a comunidade! Se encontrares algo de errado, usa a opção "Denunciar" por baixo de cada post.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
bioshock

Eu prefiro guardar imagens em ficheiros porque:

- Os bits de uma imagem não são informação pesquisável

- Enchem a base de dados com "lixo" (consequência do ponto anterior)

- Aumenta o tráfego SQL e consequentemente pode atrasar outras operações

Dessa forma deixas para o sistema de ficheiros a tarefa de gerir as imagens (por exemplo, pode ser útil numa situação de cópia para outra pasta, sem recurso a scripts que acedam ao servidor SQL e extraiam de lá a imagem).

Pronto, deste-me 100% certezas sobre o que queria. Era isso mesmo. Eu já consegui por isto a gravar o nome do ficheiro na BD e a imagem na pasta. Vou ver agora se consigo fazer o SELECT.

Obrigado  :)

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Knitter

Depende um pouco do objectivo. Guardar imagens na BD torna-se mais simples.

A imagem em si pode não ser importante para pesquisas mas as informações da imagem são, se já tenho uma tabela para essa informações porquê estar a fazer referências a coisas que estão fora do servidor? Além disso torna um processo de backup algo simples e mais que simples de fazer backup, simples de repor caso ocorra algum problema.

Copiar imagens guardadas dentro de uma tabela é bastante simples, obter as imagens de volta também, enfim, tudo o que posso fazer com o ficheiro faço com a mesma facilidade, ou com mais facilidade, se os dados estiverem dentro de uma tabela na BD.

Quanto a encherem a BD de lixo, esse "lixo" é a informação que precisamos, qual é a diferença, a nível de informação, entre o lixo de uma imagem e o lixo dos dados de um utilizador? Informação é informação, se é útil para o sistema e se nos dá vantagem ter isso na BD, os bits de um tipo de informação são iguais aos bits de outro.

O aumento de tráfego é algo negligenciável, o número de queries serão sensivelmente o mesmo, só no momento em que temos de obter a imagem é que podemos considerar que há um envio de mais dados, já que só deveremos aceder ao campo da imagem quando precisamos da imagem, e nesse sentido, os dados enviados são os mesmos que se pedir ao servidor que me dê a imagem em disco, afinal, se preciso de ir buscar os bits da imagem à tabela, também preciso de os ir buscar se for um ficheiro em disco.

Não defendo que se coloquem imagens no servidor de bases de dados ou que se usem pastas para as guardar, tudo dependerá do projecto e do que é pretendido. Mas pessoalmente, considero o uso da BD para guardar imagens algo que facilita bastante muitas das tarefas de gestão de imagens.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
bioshock

Depende um pouco do objectivo. Guardar imagens na BD torna-se mais simples.

A imagem em si pode não ser importante para pesquisas mas as informações da imagem são, se já tenho uma tabela para essa informações porquê estar a fazer referências a coisas que estão fora do servidor? Além disso torna um processo de backup algo simples e mais que simples de fazer backup, simples de repor caso ocorra algum problema.

Copiar imagens guardadas dentro de uma tabela é bastante simples, obter as imagens de volta também, enfim, tudo o que posso fazer com o ficheiro faço com a mesma facilidade, ou com mais facilidade, se os dados estiverem dentro de uma tabela na BD.

Quanto a encherem a BD de lixo, esse "lixo" é a informação que precisamos, qual é a diferença, a nível de informação, entre o lixo de uma imagem e o lixo dos dados de um utilizador? Informação é informação, se é útil para o sistema e se nos dá vantagem ter isso na BD, os bits de um tipo de informação são iguais aos bits de outro.

O aumento de tráfego é algo negligenciável, o número de queries serão sensivelmente o mesmo, só no momento em que temos de obter a imagem é que podemos considerar que há um envio de mais dados, já que só deveremos aceder ao campo da imagem quando precisamos da imagem, e nesse sentido, os dados enviados são os mesmos que se pedir ao servidor que me dê a imagem em disco, afinal, se preciso de ir buscar os bits da imagem à tabela, também preciso de os ir buscar se for um ficheiro em disco.

Não defendo que se coloquem imagens no servidor de bases de dados ou que se usem pastas para as guardar, tudo dependerá do projecto e do que é pretendido. Mas pessoalmente, considero o uso da BD para guardar imagens algo que facilita bastante muitas das tarefas de gestão de imagens.

Compreendo o teu ponto de vista. E de certa forma tens razão no ponto em que referes que existe uma maior facilidade via BD. Eu pelo menos estou a comprovar isso, já tenho a inserção a funcionar em pleno (Regista o nome da imagem na BD e move a imagem para a pasta pretendida) mas estou-me a ver "negro" para mostrar a imagem. O google não me tem ajudado grande coisa, só encontro tópicos com as Imagens na BD.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
softklin

Essa simplicidade paga-se com consumo de recursos do servidor. Já falei da base de dados, mas posso dar outro exemplo, a memória: precisas de manipular o ficheiro (neste caso com VB.net), e devolvê-lo na página. Se o ficheiro estiver no disco, também tem de ser carregado na mesma, mas é um processo mais "directo", porque apenas implica ler o ficheiro do disco (com toda a performance do sistema de ficheiros) e enviá-lo por rede.

Quanto à questão do tráfego, eu não considero negligenciável, pelo ponto que referiste depois, pelo envio de dados extra a cada query.

(In)felizmente, tive a oportunidade de trabalhar com inserção de imagens numa base de dados MySQL, e a partir do momento em que começamos a encher a BD com imagens de mapas freguesias, notava-se um ligeiro decréscimo de performance e, naturalmente, o aumento da base de dados.


Nick antigo: softclean | Tens um projeto? | Wiki P@P

Ajuda a comunidade! Se encontrares algo de errado, usa a opção "Denunciar" por baixo de cada post.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
bioshock

Essa simplicidade paga-se com consumo de recursos do servidor. Já falei da base de dados, mas posso dar outro exemplo, a memória: precisas de manipular o ficheiro (neste caso com VB.net), e devolvê-lo na página. Se o ficheiro estiver no disco, também tem de ser carregado na mesma, mas é um processo mais "directo", porque apenas implica ler o ficheiro do disco (com toda a performance do sistema de ficheiros) e enviá-lo por rede.

Quanto à questão do tráfego, eu não considero negligenciável, pelo ponto que referiste depois, pelo envio de dados extra a cada query.

(In)felizmente, tive a oportunidade de trabalhar com inserção de imagens numa base de dados MySQL, e a partir do momento em que começamos a encher a BD com imagens de mapas freguesias, notava-se um ligeiro decréscimo de performance e, naturalmente, o aumento da base de dados.

Esses pontos que focaste, foram os pontos que o meu patrão, enquanto estagiário, mencionou e continua a mencionar (Parte web - PHP). Ele também sempre quis que eu criasse pastas para guardar as imagens pelos mesmos pontos que referiste.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Knitter

Por isso é que disse que dependerá sempre do projecto e do objectivo. O crescimento da BD será igual ao crescimento da pasta de imagens, e se a base de dados estiver bem configurada então os dados dos blobs estarão optimizados. Claro que guardar na BD implica uma camada extra de processamento, mas essa perda pode ser compensada e as vantagens no desenvolvimento e manutenção ganharem em muito a perda de performance. Aliás, eu diria que a performance é um fraco ponto de escolha, além de ser bastante dependente das configurações de armazenamento da BD... quantas vezes ajustaste as configurações de armazenamento dos campos em tabelas MySQL? Usar os valores por omissão pode ser suficiente mas irás bater em problemas de espaço e performance.

Por outro lado não percebi onde é que as queires têm um gasto adicional, serão as mesmas queries e nenhuma delas trará os dados da imagem a não ser a que pede, explicitamente, a imagem. Para todas as outras opções nunca se irá trabalhar com os campos blob, nem sequer com a tabela de imagens.

Também já trabalhei com BDs com várias imagens e nunca houve problemas de performance, já trabalhei com BDs que ocupavam até 7 GB de dados e a única coisa que era chata de fazer era o download do ficheiro de backup :) .

Não é simples dizer que a solução A é melhor que a solução B, e só comentei neste tópico porque na tua resposta indicaste pontos que são muito subjectivos, e acho que devemos ter sempre a noção que este tipo de comparações é complicado de fazer.

- Os bits de uma imagem não são informação pesquisável

Nas bases de dados não se guardam apenas informações pesquisáveis, aliás, muito pouca da informação que se guarda é efectivamente guardada com o objectivo de ser pesquisada. Ter as imagens no disco ou numa tabela não afecta a pesquisa nem é afectado pela necessidade de pesquisar alguma informação.

- Enchem a base de dados com "lixo" (consequência do ponto anterior)

Como mencionei antes, se consideramos os dados das imagens na BD como lixo, podemos ver o mesmo lixo noutros dados. E do mesmo modo, não deixam de ser lixo quando estão fora da BD. A noção de que encher uma tabela com dados por fazer perder performance só será válida se considerarmos que essa tabela é usada de forma indevida. Há sempre uma penalização, mas não será algo que se note. Por exemplo, na BD de 7GB, o espaço estava todo numa só tabela, não houve perda de performance no sistema, apesar dessa tabela ser usada em, literalmente, todas as transacções.

- Aumenta o tráfego SQL e consequentemente pode atrasar outras operações

Como é que pode aumentar o tráfego SQL? Porque é que as outras operações terão de estar envolvidas? As imagens serão apenas acedidas quando forem explicitamente necessárias, fora isso, é uma tabela em que não se toca.

Resumindo, acho que os pontos levantados fogem completamente ao que se deve procurar quando estamos a desenvolver o sistema, como é que podemos avaliar a performance se não temos meios de comparação e pior, se essa penalização de performance afectar 1% do sistema numa funcionalidade acedida 1 vez por ano por um utilizador, será de lhe devemos dar assim tanta atenção, e perder alguma eventual vantagem que se tenha de outra forma?

Novamente, não devendo nem uma nem outra solução, apenas que devemos olhar para o problema de outra forma. Não tendo grandes informações sobre o objectivo, qualquer das duas soluções é viável.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
softklin

Bem, quanto à performance, sou suspeito por falar, porque agora que me lembro, as queries eram feitas com "SELECT * FROM ...", que é uma prática bastante condenável, o que vai de encontro ao que disseste.

O tráfego adicional, apenas me referia às queries de consulta de imagens, pois é certo que se guardar as imagens e nenhuma query solicitar dados de lá, não irá gerar tráfego adicional nenhum.

O que me faz mais confusão é o facto de inserir imagens, que por si, não podem ser passíveis de pesquisa, sem depender de outros campos. Eu referia-me a poderes fazer um "SELECT nome FROM pessoas WHERE idade >= 18", e o que está a ser feito em 'idade' não pode ser (pelo menos não encontro um contra-exemplo que faça sentido) feito num campo BLOB.

Contudo, é como dizes, são dois pontos de vista distintos. Concordo que o desenvolvimento pode ficar facilitado em bastantes situações optando por guardar imagens na base de dados.


Li o documento que deixaste, e bem, sou forçado a concordar com 4 pontos, excepto o ponto da Extensibility, porque não percebo como é que esses dados podem ser indexados (remete ao exemplo dos campos serem passíveis de pesquisa).

Os pontos contra, no fundo, já foram aqui discutidos.


Nick antigo: softclean | Tens um projeto? | Wiki P@P

Ajuda a comunidade! Se encontrares algo de errado, usa a opção "Denunciar" por baixo de cada post.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
falk0n

Para além do que foi dito fugindo um pouco ao tópico (se for permitido), numa situação em que a imagem é um "asset" e que deve ser preservado como tal penso que esta possa estar dentro da base de dados pois só com o recurso a queries dentro desta é que é possível de obter a dita imagem, mas caso seja uma imagem de qualquer coisa banal penso que poderia estar fora da base de dados e poder ser "indexada" por um motor de pesquisa por exemplo.

Se poderem comentar gostaria de ler as vossas opiniões sobre este assunto.

Nuno Martins

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
bioshock

Bem eu já pus isto a funcionar +/- como eu queria. A fazer o move das imagens para uma pasta, a guardar apenas e só o nome da imagem na BD e a fazer o SELECT na pasta para mostrar as imagens.

No meu caso, é preferível assim, creio!

Podem estar aceder à pasta várias pessoas, a fazer uploads várias vezes e neste caso, este SELECT, sempre que se entra na aplicação, é obrigatório!

Portanto, como vão haver centenas e centenas de imagens (Ainda não assumi o facto de poder redimensiona-las para poupar espaço), a serem constantemente "uppadas" e várias vezes acedidas...

Temos sempre que ter em conta o servidor onde estas vão ser armazenadas, se é necessário ou não haver um redimensionamento / outra situação qualquer que surja.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
Knitter

(...) mas caso seja uma imagem de qualquer coisa banal penso que poderia estar fora da base de dados e poder ser "indexada" por um motor de pesquisa por exemplo.

Se um dos objectivos é a indexação ou a disponibilização directa através de listagem, então, qualquer argumento a favor da base de dados pode ser ignorado porque um dos requisitos é que esteja acessível através de listagem, voltamos aos objectivos/requisitos do projecto.

Por norma, a minha escolha recai para o uso da BD, mas tudo dependerá do projecto, por exemplo, implementei há relativamente pouco tempo um sistema para colocação de notícias, quase CMS, e a escolha óbvia foi a colocação de imagens dentro de pastas. Isto porque fazer toda a gestão da imagem, com as várias referências directas no texto da notícia, fornecer ao utilizador um editor WYSIWYG, e garantir que as imagens apareciam correctamente tendo as imagens dentro de uma base de dados tornava-se muito mais complicado e exigente que simplesmente colocar numa pasta e proteger de acesso directo com .htaccess.

Por outro lado, para o mesmo projecto, todas as imagens de produtos estão dentro da BD. Torna-se mais simples gerir, não tenho o problema de manter a relação entre a BD e a pasta com os ficheiros, e um backup dos produtos é feito com um passo e leva todos os dados relevantes. Repor esse backup é também simples de fazer e relacionar a mesma imagem com vários produtos, algo que neste caso acontece devido à especificidade dos produtos, é tão simples como relacionar quaisquer outros dois registos de tabelas. Se tivesse usado pastas e guardado os ficheiros em pastas, neste caso teria dado mais trabalho. A nível de performance, os testes feitos demonstram que fica ela por ela, mas a performance nunca foi algo considerado.

Pwyll, esse link tem alguma idade, e mais que isso, parece muito relativo às limitações do MS SQL Server, de qualquer modo, este é um tema que divide bastante, é fácil encontrar longas discussões sobre isto.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites
softklin

Peguei numa pá para vir aqui actualizar o link que o Knitter deixou, uma vez que o artigo não está disponível, e é de leitura bastante interessante.

http://www.oracle.com/technetwork/testcontent/why-images-in-database-132153.pdf


Nick antigo: softclean | Tens um projeto? | Wiki P@P

Ajuda a comunidade! Se encontrares algo de errado, usa a opção "Denunciar" por baixo de cada post.

Partilhar esta mensagem


Ligação para a mensagem
Partilhar noutros sites

Crie uma conta ou ligue-se para comentar

Só membros podem comentar

Criar nova conta

Registe para ter uma conta na nossa comunidade. É fácil!

Registar nova conta

Entra

Já tem conta? Inicie sessão aqui.

Entrar Agora

×

Aviso Sobre Cookies

Ao usar este site você aceita os nossos Termos de Uso e Política de Privacidade. Este site usa cookies para disponibilizar funcionalidades personalizadas. Para mais informações visite esta página.