IMAGEM EM SQL SERVER
Bom dia!!!!
Pessoal voce ja montaram algum sistema que grava imagens como parte de um registro?
Tenho um cadastro onde tera uma tabela em SQL SERVER que armazenara dados: nome endereco cpf rg etc etc. e junto uma imagem scaneada dos documentos.
Minha duvida. Oque voces recomendam? Gravar a imagen dentro do banco de dados ou criar um campo onde se aponta o caminho de onde esta localizada a imagem?
é uma assunto muito polemico e precisava tomar uma decisao...
Abracos!
Pessoal voce ja montaram algum sistema que grava imagens como parte de um registro?
Tenho um cadastro onde tera uma tabela em SQL SERVER que armazenara dados: nome endereco cpf rg etc etc. e junto uma imagem scaneada dos documentos.
Minha duvida. Oque voces recomendam? Gravar a imagen dentro do banco de dados ou criar um campo onde se aponta o caminho de onde esta localizada a imagem?
é uma assunto muito polemico e precisava tomar uma decisao...
Abracos!
Cara é o seguinte..to mandando um exemplo de como fazer isso em access..aàé só adaptar.
Agora..depende muito do seguinte detalhe: LOCAL DAS FOTOS
- se vc tem esse local fixo e seguro...aconselho gravar somente o path da foto..assim o banco fica light
- se esse local n é seguro, teria q gravar a imagem mesmo..mas o banco daria uma inxada..então..pensa ae
boa sorte e sucesso
Não é aconselhável gravar imagens diretamente na base de dados.
Pois a sua base ficará com um tamnho ENORME com muito poucos dados, fora que o tráfego na rede ficará imenso, caso algumas máquinas ao mesmo tempo solicite a visualização de uma imagem no seu bco de dados.
Sem sombra de dúvidas, é aconselhável VC gravar o caminho da imagem+nome da imagem no seu bco, e no seu sistema VC buscar neste caminh + nome da imagem e mostrar a imagem para o usuário.
Assim o seu tráfego na rede ficará muito menor, e seu sistema será mais rápido (pensando ao longo do tempo, e não no AGORA)
Pois a sua base ficará com um tamnho ENORME com muito poucos dados, fora que o tráfego na rede ficará imenso, caso algumas máquinas ao mesmo tempo solicite a visualização de uma imagem no seu bco de dados.
Sem sombra de dúvidas, é aconselhável VC gravar o caminho da imagem+nome da imagem no seu bco, e no seu sistema VC buscar neste caminh + nome da imagem e mostrar a imagem para o usuário.
Assim o seu tráfego na rede ficará muito menor, e seu sistema será mais rápido (pensando ao longo do tempo, e não no AGORA)
Eu discordo dos nossos amigos...ICHIHARA irá usar o banco de dados SQL SERVER (um dos melhores SGBD) as imagens são gravadas internamente no Banco de Dados (formato binario 0 E 1) e na minha opinião não existe lugar + seguro que no banco de dados(de preferência de ótimo desempenho). Em relação a performace da rede pode ficar tranquilo se vc tiver uma rede de 100 megabits conectadas a um swith (hub nem pensar)...
P.S: Se vc gravar as imagens em outro lugar terá sempre que realizar 2 backups...(Um das imagens e o outro dos dados).
P.S: Se vc gravar as imagens em outro lugar terá sempre que realizar 2 backups...(Um das imagens e o outro dos dados).
Concordo FRAU...tanto q no exemplo q mandei tem essa situação..gravando binariamente..só que como vc mesmo disse...tudo vai depender da estrutura de rede q ele possuir..
então...aàele vai ter q decidir..o melhor caminho a tomar lá..analisando e estudando a situação
boa sorte pra ele!!
é verdade SINKERTEC (A decisão será somente dele). Quanto mais informações e opiniões nosso amigo ICHIHARA obter + fácil será a decisão.
Abrs.,
Frau.
Abrs.,
Frau.
Obrigado!!
Estou aberto para mais opinioes!
Estou aberto para mais opinioes!
Bom, as informações que passei são de DBA (sou DBA tbem, e não só EU como 90% dos DBAÂÂ's não recomendam que faça isso).
Vai do PROGRAMADOR, sou PROGRAMADOR e DBA, e isso me ajuda e muito em tomar muitas decisões. E uma decisão que JAMAIS irei tomar em nenhum cliente, pensando em VELOCIDADE/REDE/PERFORMANCE/SEGURANÇA é exatamente a de não gravar imagem diretamente na BASE.
Se o problema é SEGURANÇA, VC pode criar uma pasta no servidor, onde só o sistema têm acesso (cria-se um USER/SENHA interno só pro sistema acessar e pronto). Com só o sistema acessando tal pasta, só é possÃÂÂvel ver a imagem diretamente pelo sistema (da mesma forma que seria se fosse gravado diretamente na base).
Agora, façam testes e veja como que fica o tamanho de sua base de dados, com 10 registros gravados com IMAGEM gravada diretamente na BASE, com uma base de teste criada do ZERO, e depois apague estes 10 registros, se possÃÂÂvel, apague a base e re-crie do ZERO outra BASE/TABELA e inclua estes 10 registros, só que no campo da IMAGEM, ao invés de ser BINARIO, crie o campo como VARCHAR(200) e faça a comparação do tamanho.
VC irá notar uma grande diferença só pra 10 registros entre elas... Imagine pra 1000/100000000000000000 registros??? Compensa?? E a velocidade da REDE?? Vale a pena mesmo arriscar???
PENSEM melhor e verão...
Vai do PROGRAMADOR, sou PROGRAMADOR e DBA, e isso me ajuda e muito em tomar muitas decisões. E uma decisão que JAMAIS irei tomar em nenhum cliente, pensando em VELOCIDADE/REDE/PERFORMANCE/SEGURANÇA é exatamente a de não gravar imagem diretamente na BASE.
Se o problema é SEGURANÇA, VC pode criar uma pasta no servidor, onde só o sistema têm acesso (cria-se um USER/SENHA interno só pro sistema acessar e pronto). Com só o sistema acessando tal pasta, só é possÃÂÂvel ver a imagem diretamente pelo sistema (da mesma forma que seria se fosse gravado diretamente na base).
Agora, façam testes e veja como que fica o tamanho de sua base de dados, com 10 registros gravados com IMAGEM gravada diretamente na BASE, com uma base de teste criada do ZERO, e depois apague estes 10 registros, se possÃÂÂvel, apague a base e re-crie do ZERO outra BASE/TABELA e inclua estes 10 registros, só que no campo da IMAGEM, ao invés de ser BINARIO, crie o campo como VARCHAR(200) e faça a comparação do tamanho.
VC irá notar uma grande diferença só pra 10 registros entre elas... Imagine pra 1000/100000000000000000 registros??? Compensa?? E a velocidade da REDE?? Vale a pena mesmo arriscar???
PENSEM melhor e verão...
FRAU:
Bem colocado, mas não está lá muito certo. se me permitir complementar, no MS-Access as imagens (e arquivos de um modo geral) também são salvos em formato binário (binário longo), no Oracle são gravados como arquivos comuns, compactados e por aàvai.
Desse modo, mesmo binário, não dá para desprezar o tamanho do arquivo e a diferença que ele faz nos registros. Mas não é uma idéia descartável, só por conta disso, ao contrário.
Não creio que seja o uso da gravação de imagens / arquivos o único "culpado" por uma taxa de crescimento exponencial de um banco de dados. Na verdade, a estrutura dos dados é bem mais importante, até nessa questão.
Só para dar um exemplo do que estou dizendo, vejamos.
Um banco com as tabelas:
PRODUTOS (com fotos)
CLIENTES (com fotos)
USUARIOS (com fotos)
Vamos analisar.
A tabela PRODUTOS terá fotos em TODOS os registros, mas essas fotos serão substituÃÂÂdas de tempos em tempos, para "mudar a vitrine". Sendo assim, armazenar o CAMINHO das imagens pode ser uma idéia mais razoável, pois o volume de registros e alterações que eles sofreriam poderia implicar em uma taxa de cresimento maior do que a desejada e em consumo de recursos igualmente alta.
A tabela USUARIOS conterá poucos registros, são só os funcionários com direito de acesso ao aplicativo, e uma vez cadastrados, não estarão substituindo suas fotos sempre, de modo que salvar a foto é uma idéia bastante interessante, fácil de aplicar e que dá bom resultado.
A tabela CLIENTES é a que conterá hipoteticamente o maior nº de registros, e não terá a obrigatoriedade da foto, pois o cliente pode se recusar á isso, e é direito dele. Desse modo, reservar um campo para as fotos em cada registro seria errado, no mÃÂÂnimo. Faz-se uma "segunda" tabela denominada FOTOSDOSCLIENTES, com os campos ID e FOTO, onde gravamos apenas as fotos que realmente serão efetuadas, e deixamos a tabela de clientes livre e desempedida para trabalhar "macio".
O que estou dizendo, então, não é contrariando as suas colocações, FRAU, mas apenas complementando, pois cada caso é diferente. Só uma boa análise (pontual e estimada) é que pode chegar mais perto da solução ideal. E nesse caso então, mesmo o MS-Access é um mecanismo útil. Só para lembrar, podemos na mesma aplicação utilizar vários MDBs (até 5 em uma mesma instrução, segundo a M$), então dá para ir razoavelmente longe, mesmo com ele. Agora, inquestionavelmente, o SQL Server é um SGDB e o MS-Access, se não programado, é apenas um banco de dados, o que é bem diferente.
ICHIHARA:
O "pai" da questão, e eu deixei para o fim. Não sei se ajuda, mas o que eu aconselho é levar em conta o futuro da aplicação.
Continuando o que eu complementei acima, dê uma analisada na estrutura dos dados que você vai utilizar, faça testes para chegar á taxa média de crescimento do banco de dados (com e sem imagem) para só depois decidir.
Um exemplo de situação:
Eu fiz um site para alguns professores, que guardam arquivos de diversos formatos (incluindo imagens, ppts, docs, pdfs, rar, zip e exes), são artigos e arquivos relativos ás matérias que lecionam.
Eles pediram que ninguém pudesse copiar algumas categorias de artigos, liberando outras, validando isso contra senhas dos alunos, professores e colaboradores.
Seria fácil dispÃÂ'r esses arquivos nas pastas do site e controlar o acesso com o ASPNet (membership, profiles etc). E eu fiz isso, ok?
Mas o que o provedor deles não havia explicado muito bem era como a coisa funcionava... Eles pagavam um adicional mensal pelo volume em Mb de arquivos que estivessem nas pastas do site, sempre que esse volume ultrapassasse a cota dos 3Mb (quanta coisa, não??)
Hehehe, o provedor não contava com o fato de eu ler o contrato e de que ee mesmo oferecia os bancos de dados sem limite por utilização. A saÃÂÂda que eu achei foi essa. Gravava tudo em um banco, e do MS-Access mesmo, junto com as outras tabelas da aplicação.
O site acabou sendo aprovado, eles não pagaram mais os adicionais, e perguntaram meses depois se seria interessante optar pelo SQL Server. Sem pensar muito, eu disse que "sim, pois é um sistema client/server nativo"...
Pasmem agora: Tudo alterado, o sistema rodando perfeitinho aqui nas minhas máquinas, publiquei no site.
Qual não foi a minha surpresa, quando o site já migrado apresentava um desempenho nada manos de 30% MENOR do que com o MS-Access!!! Ætristeza!!!
A aplicação gravava todos os arquivos no banco, tanto no MS-Access quanto no SQL Server... Não gravo nada em pastas, nem temporários para montar as páginas com as imagens, é tudo direto do banco para a página do cliente via context... Por quê então era mais lento no SQL Server???
A primeira idéia era a de que o volume de acessos ao site dela tivesse aumentado muito, e com isso, diminuia o desempenho. Furado.
A segunda hipótese era que o host estivesse mudando algum sitema dele e isso estivesse interferindo. Outro furo nÂÂ'água.
A resposta veio depois de mais um mês. Estava na minha cara o tempo todo, e eu não queria ver. Era o SQL Server mesmo!!
Não é que o SQL Server seja inferior ao MS-Access, nem de longe estou dizendo isso. é que ESSE servidor SQL Server especÃÂÂfico tem um volume de acessos muito grande e serve á um número grande de outros sites / contas. Assim, o desempenho dele é, digamos, sofrÃÂÂvel.
Esse exemplo pode não parecer muito bom, mas é para que você tenha uma idéia de quão variados são os pontos á se "pesar" antes de decidir.
Resumindo o que eu já alonguei:
- Calcule as taxas de crescimento médias do seu banco de dados, tabela por tabela, e no global;
- Avalie bem a quantidade de acessos simultâneos esse banco terá;
- Se o banco fÃÂ'r exclusivo á sua aplicação, reduza ao máximo a quantidade de conexões abertas, preferencialmente só abra uma conexão para:
A - Carregar um ou mais registros;
B - Salvar uma alteração;
C - Salvar um lote de alterações.
(E encerre a conexão assim que a tarefa for realizada);
- Avalie os recursos de tráfego que a rede comporta em três nÃÂÂveis:
1 - Ótimo (1% á 10% de utilização dos recursos).
2 - Regular (11% á 15% de utilização dos recursos).
3 - RuÃÂÂm (16% á 29% de utilização dos recursos).
- Refaça as instruções SQL para que se encaixem melhor nos nÃÂÂveis acima (traga apenas os dados necessários, utilize corretamente os JOIN, utilize-se de ÃÂÂndices existente, evite campos "nuláveis" etc);
- Jogue no SGDB toda a carga de instruções SQL de execução e consulta que puder. Isso "alivia" o tráfego de rede e se vale da performance maior do servidor, deixando a estação livre para suas atividades.
- LIMITE O TAMANHO DAS IMAGENS àSEREM GRAVADAS, BEM COMO SUAS DIMENS̉ۢES. Se estiver usando uma linguagem DotNet, você pode redimensionar facilmente a imagem para o tamanho adequado, sem distorções, antes de gravá-la.
- Grave não apenas a imagem, mas também o tipo MIME e o tamanho da mesma. Isso vai facilitar bastante na carga da imagem, depois de gravada no banco.
- Avalie bem a necessidade de segurança / privacidade das imagens, calculando (e, claro, cobrando) os custos para cada opção, tanto em prazos quanto em valores.
E coisas desse gênero.
Se conselho fosse bom, seria pago.
O que devemos fazer é ouvir o conselho todo, digerir apenas o que nos presta e descartar o resto, ou guardar para mais tarde, se a fome apertar hehehe.
O seu caso difere do meu, assim como dos de quaisquer outros
A gente pode trocar noções do que já sofreu, do que já funcionou conosco, mas pisar nas suas pedras (avaliar a situação) será sempre só você mesmo.
Valew?
Bem colocado, mas não está lá muito certo. se me permitir complementar, no MS-Access as imagens (e arquivos de um modo geral) também são salvos em formato binário (binário longo), no Oracle são gravados como arquivos comuns, compactados e por aàvai.
Desse modo, mesmo binário, não dá para desprezar o tamanho do arquivo e a diferença que ele faz nos registros. Mas não é uma idéia descartável, só por conta disso, ao contrário.
Não creio que seja o uso da gravação de imagens / arquivos o único "culpado" por uma taxa de crescimento exponencial de um banco de dados. Na verdade, a estrutura dos dados é bem mais importante, até nessa questão.
Só para dar um exemplo do que estou dizendo, vejamos.
Um banco com as tabelas:
PRODUTOS (com fotos)
CLIENTES (com fotos)
USUARIOS (com fotos)
Vamos analisar.
A tabela PRODUTOS terá fotos em TODOS os registros, mas essas fotos serão substituÃÂÂdas de tempos em tempos, para "mudar a vitrine". Sendo assim, armazenar o CAMINHO das imagens pode ser uma idéia mais razoável, pois o volume de registros e alterações que eles sofreriam poderia implicar em uma taxa de cresimento maior do que a desejada e em consumo de recursos igualmente alta.
A tabela USUARIOS conterá poucos registros, são só os funcionários com direito de acesso ao aplicativo, e uma vez cadastrados, não estarão substituindo suas fotos sempre, de modo que salvar a foto é uma idéia bastante interessante, fácil de aplicar e que dá bom resultado.
A tabela CLIENTES é a que conterá hipoteticamente o maior nº de registros, e não terá a obrigatoriedade da foto, pois o cliente pode se recusar á isso, e é direito dele. Desse modo, reservar um campo para as fotos em cada registro seria errado, no mÃÂÂnimo. Faz-se uma "segunda" tabela denominada FOTOSDOSCLIENTES, com os campos ID e FOTO, onde gravamos apenas as fotos que realmente serão efetuadas, e deixamos a tabela de clientes livre e desempedida para trabalhar "macio".
O que estou dizendo, então, não é contrariando as suas colocações, FRAU, mas apenas complementando, pois cada caso é diferente. Só uma boa análise (pontual e estimada) é que pode chegar mais perto da solução ideal. E nesse caso então, mesmo o MS-Access é um mecanismo útil. Só para lembrar, podemos na mesma aplicação utilizar vários MDBs (até 5 em uma mesma instrução, segundo a M$), então dá para ir razoavelmente longe, mesmo com ele. Agora, inquestionavelmente, o SQL Server é um SGDB e o MS-Access, se não programado, é apenas um banco de dados, o que é bem diferente.
ICHIHARA:
O "pai" da questão, e eu deixei para o fim. Não sei se ajuda, mas o que eu aconselho é levar em conta o futuro da aplicação.
Continuando o que eu complementei acima, dê uma analisada na estrutura dos dados que você vai utilizar, faça testes para chegar á taxa média de crescimento do banco de dados (com e sem imagem) para só depois decidir.
Um exemplo de situação:
Eu fiz um site para alguns professores, que guardam arquivos de diversos formatos (incluindo imagens, ppts, docs, pdfs, rar, zip e exes), são artigos e arquivos relativos ás matérias que lecionam.
Eles pediram que ninguém pudesse copiar algumas categorias de artigos, liberando outras, validando isso contra senhas dos alunos, professores e colaboradores.
Seria fácil dispÃÂ'r esses arquivos nas pastas do site e controlar o acesso com o ASPNet (membership, profiles etc). E eu fiz isso, ok?
Mas o que o provedor deles não havia explicado muito bem era como a coisa funcionava... Eles pagavam um adicional mensal pelo volume em Mb de arquivos que estivessem nas pastas do site, sempre que esse volume ultrapassasse a cota dos 3Mb (quanta coisa, não??)
Hehehe, o provedor não contava com o fato de eu ler o contrato e de que ee mesmo oferecia os bancos de dados sem limite por utilização. A saÃÂÂda que eu achei foi essa. Gravava tudo em um banco, e do MS-Access mesmo, junto com as outras tabelas da aplicação.
O site acabou sendo aprovado, eles não pagaram mais os adicionais, e perguntaram meses depois se seria interessante optar pelo SQL Server. Sem pensar muito, eu disse que "sim, pois é um sistema client/server nativo"...
Pasmem agora: Tudo alterado, o sistema rodando perfeitinho aqui nas minhas máquinas, publiquei no site.
Qual não foi a minha surpresa, quando o site já migrado apresentava um desempenho nada manos de 30% MENOR do que com o MS-Access!!! Ætristeza!!!
A aplicação gravava todos os arquivos no banco, tanto no MS-Access quanto no SQL Server... Não gravo nada em pastas, nem temporários para montar as páginas com as imagens, é tudo direto do banco para a página do cliente via context... Por quê então era mais lento no SQL Server???
A primeira idéia era a de que o volume de acessos ao site dela tivesse aumentado muito, e com isso, diminuia o desempenho. Furado.
A segunda hipótese era que o host estivesse mudando algum sitema dele e isso estivesse interferindo. Outro furo nÂÂ'água.
A resposta veio depois de mais um mês. Estava na minha cara o tempo todo, e eu não queria ver. Era o SQL Server mesmo!!
Não é que o SQL Server seja inferior ao MS-Access, nem de longe estou dizendo isso. é que ESSE servidor SQL Server especÃÂÂfico tem um volume de acessos muito grande e serve á um número grande de outros sites / contas. Assim, o desempenho dele é, digamos, sofrÃÂÂvel.
Esse exemplo pode não parecer muito bom, mas é para que você tenha uma idéia de quão variados são os pontos á se "pesar" antes de decidir.
Resumindo o que eu já alonguei:
- Calcule as taxas de crescimento médias do seu banco de dados, tabela por tabela, e no global;
- Avalie bem a quantidade de acessos simultâneos esse banco terá;
- Se o banco fÃÂ'r exclusivo á sua aplicação, reduza ao máximo a quantidade de conexões abertas, preferencialmente só abra uma conexão para:
A - Carregar um ou mais registros;
B - Salvar uma alteração;
C - Salvar um lote de alterações.
(E encerre a conexão assim que a tarefa for realizada);
- Avalie os recursos de tráfego que a rede comporta em três nÃÂÂveis:
1 - Ótimo (1% á 10% de utilização dos recursos).
2 - Regular (11% á 15% de utilização dos recursos).
3 - RuÃÂÂm (16% á 29% de utilização dos recursos).
- Refaça as instruções SQL para que se encaixem melhor nos nÃÂÂveis acima (traga apenas os dados necessários, utilize corretamente os JOIN, utilize-se de ÃÂÂndices existente, evite campos "nuláveis" etc);
- Jogue no SGDB toda a carga de instruções SQL de execução e consulta que puder. Isso "alivia" o tráfego de rede e se vale da performance maior do servidor, deixando a estação livre para suas atividades.
- LIMITE O TAMANHO DAS IMAGENS àSEREM GRAVADAS, BEM COMO SUAS DIMENS̉ۢES. Se estiver usando uma linguagem DotNet, você pode redimensionar facilmente a imagem para o tamanho adequado, sem distorções, antes de gravá-la.
- Grave não apenas a imagem, mas também o tipo MIME e o tamanho da mesma. Isso vai facilitar bastante na carga da imagem, depois de gravada no banco.
- Avalie bem a necessidade de segurança / privacidade das imagens, calculando (e, claro, cobrando) os custos para cada opção, tanto em prazos quanto em valores.
E coisas desse gênero.
Se conselho fosse bom, seria pago.
O que devemos fazer é ouvir o conselho todo, digerir apenas o que nos presta e descartar o resto, ou guardar para mais tarde, se a fome apertar hehehe.
O seu caso difere do meu, assim como dos de quaisquer outros
A gente pode trocar noções do que já sofreu, do que já funcionou conosco, mas pisar nas suas pedras (avaliar a situação) será sempre só você mesmo.
Valew?
Luiz Cesar, já que vc é DBA gostaria de deixar duas perguntas:
Porque os desenvolvedores dos bancos de dados do porte (MICROSOFT SQL SERVER) criaram o tipo de campo IMAGEM? Para que propósito serve o campo IMAGEM afinal?
Obrigado pela atenção,
Frau.
Porque os desenvolvedores dos bancos de dados do porte (MICROSOFT SQL SERVER) criaram o tipo de campo IMAGEM? Para que propósito serve o campo IMAGEM afinal?
Obrigado pela atenção,
Frau.
FRAU,
Este campo é pra gravar imagens mesmo.
Só que mais para INTERESSE da M$, em fazer a máquina servidor "explodir" e fazer VC comprar máquinas mais potentes, do que pra utilização diária mesmo.
SE VC conversar com qualquer DBA por aÃÂÂ, VC verá que este campo existe lá, mas se pudéssemos tirar de lá por causa do RESULTADO que este campo pode trazer nas aplicações, tirarÃÂÂamos COM PRAZER.
Infelizmente, ainda existes PROGRAMADORES que insistem em usar estes campos e achar que é a OITAVA MARAVILHA do mundo, e depois batem cabeça do Pq o sistema tá lento... Nestes casos, só INFORMO e mando ele se virar, pois até apostilas para os programadores de onde trabalho, recomendando o não uso deste campo, eu já fiz.
E se têm aplicações novas na empresa, onde sou o responsável pela base, eu BARRO toda a idéia de gravar imagem no bco e explicando o PQ com NÃÅ¡MEROS, EXEMPLOS e tudo mais....
Este campo é pra gravar imagens mesmo.
Só que mais para INTERESSE da M$, em fazer a máquina servidor "explodir" e fazer VC comprar máquinas mais potentes, do que pra utilização diária mesmo.
SE VC conversar com qualquer DBA por aÃÂÂ, VC verá que este campo existe lá, mas se pudéssemos tirar de lá por causa do RESULTADO que este campo pode trazer nas aplicações, tirarÃÂÂamos COM PRAZER.
Infelizmente, ainda existes PROGRAMADORES que insistem em usar estes campos e achar que é a OITAVA MARAVILHA do mundo, e depois batem cabeça do Pq o sistema tá lento... Nestes casos, só INFORMO e mando ele se virar, pois até apostilas para os programadores de onde trabalho, recomendando o não uso deste campo, eu já fiz.
E se têm aplicações novas na empresa, onde sou o responsável pela base, eu BARRO toda a idéia de gravar imagem no bco e explicando o PQ com NÃÅ¡MEROS, EXEMPLOS e tudo mais....
Tópico encerrado , respostas não são mais permitidas