Gravando Arquivos Binários no PostgreSQL
O armazenamento de arquivos em banco de dados Objeto-Relacional possui vantagens em relação à organização já que tudo estaria armazenado no banco. A integridade e segurança também estariam sendo garantidas pelo SGBD, porém existem as desvantagens. É o caso de precisar do seu código para visualização do arquivo. Caso você tenha armazenado uma imagem no banco, para visualizar você teria que utilizar um script que permitisse a interpretação do binário no browser, por exemplo.
Imagine um site que possui arquivos restritos a certo grupo de usuários. Se estes arquivos estivessem armazenados diretamente no HD do servidor juntamente com os códigos html e php, você poderia utilizar um cliente FTP ou até mesmo a barra de endereço do browser para ter acesso a eles, isso se você conhecer o diretório onde os documentos se encontram. Porém com os arquivos armazenados no Banco isso não seria possível, pois o usuário precisaria de um script que acessasse a base de dados e lhe fornecesse o binário deste arquivo.
Vou utilizar no exemplo o banco de dados PostgreSQL por ser um banco Objeto-Relacional, além de ser o mais avançado banco de dados de código livre disponível.
Existem algumas maneiras de inserir códigos binários de arquivos em banco de dados não relacionais. No MySQL uma solução é o campo BLOB (Binary Large Object), porém você tem que utilizar alguns artifícios para o armazenamento. Há caracteres que são “rejeitados” por esse tipo de campo, se for inserido o binário sem que esses caracteres sejam escapados, provavelmente a integridade do arquivo será afetada.
Uma solução encontrada por mim, não sei se é a mais correta, mas foi converter pra uma tabela de criptografia mais simples, como a Base64, que transforma qualquer caractere de 8 bits num sub-grupo de 6 bits presentes na maioria das tabelas de codificação. Isso reduz a quantidade de caracteres possíveis para [A-za-z0-9+/=] que é facilmente entendido pelo campo BLOB, mas o arquivo fica salvo com um tamanho 33% maior do que numa tabela normal de 8-bits.
[Nota do Editor: O comando correto para se usar com o MySQL é o addslashes()]
No PostgreSQL também é possível usar um campo semelhante ao BLOB o ByteA. A vantagem em relação ao uso do MySQL é que para o postgresql o php possui uma função chamada pg_escape_bytea(), esta função exige PostgreSQL 7.2 ou superior, que retorna valores de byte octais prefixados por \ (ex.: \032). Os usuários devem converter de volta para binários quando quiserem recuperar os dados com o comando pg_unescape_bytea(). Desconheço se o MySQL possui um comando semelhando a este.
Vamos agora mostrar a maneira de se armazenar arquivos como objetos relacionais no PostgreSQL.
Imagine um site que possui arquivos restritos a certo grupo de usuários. Se estes arquivos estivessem armazenados diretamente no HD do servidor juntamente com os códigos html e php, você poderia utilizar um cliente FTP ou até mesmo a barra de endereço do browser para ter acesso a eles, isso se você conhecer o diretório onde os documentos se encontram. Porém com os arquivos armazenados no Banco isso não seria possível, pois o usuário precisaria de um script que acessasse a base de dados e lhe fornecesse o binário deste arquivo.
Vou utilizar no exemplo o banco de dados PostgreSQL por ser um banco Objeto-Relacional, além de ser o mais avançado banco de dados de código livre disponível.
Existem algumas maneiras de inserir códigos binários de arquivos em banco de dados não relacionais. No MySQL uma solução é o campo BLOB (Binary Large Object), porém você tem que utilizar alguns artifícios para o armazenamento. Há caracteres que são “rejeitados” por esse tipo de campo, se for inserido o binário sem que esses caracteres sejam escapados, provavelmente a integridade do arquivo será afetada.
Uma solução encontrada por mim, não sei se é a mais correta, mas foi converter pra uma tabela de criptografia mais simples, como a Base64, que transforma qualquer caractere de 8 bits num sub-grupo de 6 bits presentes na maioria das tabelas de codificação. Isso reduz a quantidade de caracteres possíveis para [A-za-z0-9+/=] que é facilmente entendido pelo campo BLOB, mas o arquivo fica salvo com um tamanho 33% maior do que numa tabela normal de 8-bits.
[Nota do Editor: O comando correto para se usar com o MySQL é o addslashes()]
No PostgreSQL também é possível usar um campo semelhante ao BLOB o ByteA. A vantagem em relação ao uso do MySQL é que para o postgresql o php possui uma função chamada pg_escape_bytea(), esta função exige PostgreSQL 7.2 ou superior, que retorna valores de byte octais prefixados por \ (ex.: \032). Os usuários devem converter de volta para binários quando quiserem recuperar os dados com o comando pg_unescape_bytea(). Desconheço se o MySQL possui um comando semelhando a este.
Vamos agora mostrar a maneira de se armazenar arquivos como objetos relacionais no PostgreSQL.
Olá cara ! mto bom seu artigo !
Tipo, esse "$objeto" que você está fechando, onde você esta instanciando ele ?
see ya
Tipo, esse "$objeto" que você está fechando, onde você esta instanciando ele ?
see ya
05/06/2006 8:08am
(~18 anos atrás)
Poderia ainda utilizar o access do apache pra garantir segurança.
02/09/2005 1:09pm
(~19 anos atrás)
Guardar imagens realmente seria uma atitude ruim. BLOB CLOB costumam armazenar documentos do tipo "Microsoft Office" (word,powerpoint...)
Agora se o caso for guardar imagens, mais prático seria utilizar o banco para armazenar as pastas de cada usuário(não o conteúdo e sim o nome do folder) e utilizar o php para buscar e exibir as imagens desse folder.
Agora se o caso for guardar imagens, mais prático seria utilizar o banco para armazenar as pastas de cada usuário(não o conteúdo e sim o nome do folder) e utilizar o php para buscar e exibir as imagens desse folder.
02/09/2005 1:08pm
(~19 anos atrás)
é incrivel a facilidade de 'jogar' a imagem para o banco !!
porém utilizar essa estratégia para sites de fotos por exemplo é inviável ! será um puta de um processamento para visulizar essas fotos!
o servidor com certeza nao aguentara...outro problema é que o proprio banco fica pesado!
tive oportunidade de trabalhar num site desse estilo e tinhamos Gigabytes de imagem (em disco), eram milhares de albuns e fotos! imagine essas imagens todas em BD!
apenas em poucos casos é interessante guardar imagens no banco!
e outra, o servidor Linux com Apache tem muitos recursos de segurança que 'garatem' o acesso restrito a tais imagens em disco!
;)
porém utilizar essa estratégia para sites de fotos por exemplo é inviável ! será um puta de um processamento para visulizar essas fotos!
o servidor com certeza nao aguentara...outro problema é que o proprio banco fica pesado!
tive oportunidade de trabalhar num site desse estilo e tinhamos Gigabytes de imagem (em disco), eram milhares de albuns e fotos! imagine essas imagens todas em BD!
apenas em poucos casos é interessante guardar imagens no banco!
e outra, o servidor Linux com Apache tem muitos recursos de segurança que 'garatem' o acesso restrito a tais imagens em disco!
;)
29/08/2005 7:03pm
(~19 anos atrás)
no entando na hora de visualizar a imagem está aparecendo bugada.
O que pode ser ?
see ya !