Tenha um aplicação WEB e estou travado em uma situação:
Tenho uma tela que anexo um arquivo PDF…
Depois de ser anexado eu pego esse arquivo e transformo em byte[] e gravo no MYSQL como BLOB.
Porém não estou conseguindo fazer o inverso, ou seja, preciso pegar esse byte[] que esta no banco e listar ele na tela, que seja em um link do tipo “Visualizar”… Como faço essa conversão? Para eu pegar no Front esse PDF?
Se vc puder salvar o arquivo em um diretório, por favor faça isso.
Não é pq vc pode enfiar bytes no banco de dados q vc deve fazer isso
I
igoorsp
Então… faltou essa informação… eu nao preciso armazenar esse PDF em nenhum lugar, pois ele só irá aparecer quando o “Cliente” logar e clicar em visualizar, então seria um arquivo TEMP…
A conversão para pdf só aconteceria na hora.
D
darlan_machado
Seria um arquivo temp que deveria ficar numa pasta temp e ser lido quando o usuário necessitasse.
Ou, o melhor dos cenários, esse arquivo deve ser gerado apenas quando o usuário clica em visualizar.
J
javaflex
Se o PDF é gerado em memória não precisa ir pra disco, basta responder esses bytes como já exemplificaram.
J
josiloch
Qual a justificativa de não poder salvar um arquivo no banco?
P
programador1225
A resposta se encontra neste post do stackoverflow : Link .
J
javaflex
Existem vantagens e desvantagens na forma de manter os arquivos salvos.
Por banco, integridade e transação do processo ficam garantidos, ao contrário de guardar os arquivos por conta própria. Então depende dos requisitos/exigências, que nem sempre o mais prioritário é o máximo de desempenho.
Via banco é importante armazenar os blobs em um tablespace próprio. Os SGDBs mais profissionais suportam.
I
igoorsp
O arquivo deve ser gerado apenas quando o usuário clica em visualizar. Logo depois pode ser descartado.
I
igoorsp
Eu salvo ele no banco… mas salvo com byte, porém a conversão dele para PDF que não vou salvar em lugar algum, apenas quando o usuario solicitar.
D
darlan_machado
Se essa é a regra, não tem necessidade de armazenar no banco de dados. Você está usando uma estrutura limitada (banco de dados) para armazenar algo volátil.
J
javaflex
Mas ele nao quis dizer que salva no banco para futuras consultas? Dependendo do SGDB, não é limitado.
D
darlan_machado
SGBD utiliza o filesystem… Em algum momento, o espaço para armazenar acaba.
Sem falar da concorrência no insert…
E se o objetivo é, unicamente, apresentar quando o usuário clica no “Visualizar”, basta gerar on demand, quando é necessário. Pronto.
J
javaflex
Tudo no final é filesystem, independente dos meios. Esse limite vai ser do “disco”, não do banco. Podem ter n tablespaces, cada um em um disco/local. Se for necessário, uma única tabela de blobs em um tablespace. Sobre os gargalos concordo, mas como falei na outra mensagem, depende dos requisitos, aqui o mais prioritário é a integridade/transação, não é sistema tipo facebook.
D
darlan_machado
Justamente. Mas, tudo isso acaba em limitações a serem consideradas.
Além disso, o que ele colocou não esclarece se estes arquivos serão gerados e gravados e ficarão lá eternamente ou serão excluídos a cada período de tempo.
J
javaflex
Também cheguei a imaginar que ele gerava um relatório em PDF, neste caso nao precisaria armazenar em lugar nenhum, mas parece não ser o caso.
I
igoorsp
O seguinte, melhor eu explicar o funcionamento rapidamente…
É um sistema de advocacia, então o advogado(no caso sera o “admin”) pode criar um cliente e um processo…
O processo só existe quando tem um cliente para ele vincular. Então eu preciso deixar armazenado esse arquivo no banco (seria o processo em PDF), pois toda vez que o cliente quiser consultar, vai estar disponível…
D
darlan_machado
Ok, entendi o cenário.
Porém, ainda penso que o mais adequado é você manter os dados do processo no banco e, quando necessário, gerar o PDF a partir deles.
Mas, é uma opção fazer conforme você precisa.
De qualquer forma, você só precisa ler o BLOB: