Como comparar um blob com imagem em banco de dados

A ferramenta Entrada de Blob tem um fluxo de trabalho de exemplo. Visite Exemplos de fluxos de trabalho para saber como acessar esse e muitos outros exemplos diretamente do Alteryx Designer.

Use a ferramenta Entrada de Blob para fazer a leitura de um Binary Large Object, como, por exemplo, um arquivo de imagem ou mídia, navegando diretamente para um arquivo ou fazendo a entrada de uma lista de arquivos.

Configurar a ferramenta

A ferramenta Entrada de Blob pode ser uma ferramenta de entrada ou de passagem (onde uma lista de arquivos é transmitida para que a ferramenta os leia).

Configurar como ferramenta de entrada

Nome do arquivo: especifique o nome do arquivo que contém o blob a ser lido. Todos os tipos de arquivos são compatíveis.

Configurar como ferramenta de passagem

1. O fluxo de dados de entrada deve conter uma lista de arquivos (blobs) a serem lidos.
2. Especifique o nome do arquivo que contém o blob a ser lido. Todos os tipos de arquivos são compatíveis. O Alteryx substitui a string pelo conteúdo do fluxo de entrada.
3. Modificar o nome do arquivo usando entrada opcional: selecione a ação apropriada para substituir a string especificada no nome do arquivo acima.
   • Modificar o nome do arquivo: escolha a ação para substituir o que foi especificado no nome do arquivo acima. Como exemplo, vamos definir que o nome do arquivo seja .\dados\imagens\imagem.png
     • Acrescentar campo ao nome do arquivo como um sufixo: o conteúdo do campo especificado é adicionado após o nome do arquivo e antes da extensão. Utilizando o exemplo acima, caso o valor do campo especificado seja "maçã", o nome do arquivo resultante será .\dados\imagens\imagemmaçã.png
     • Acrescentar campo ao nome do arquivo como um prefixo: o conteúdo do campo especificado é adicionado antes do nome do arquivo. Caso o valor do campo especificado seja "banana", o nome do arquivo resultante será  .\dados\imagens\bananaimagem.png
     • Substituir o nome do arquivo pelo campo: o conteúdo do campo especificado é usado como o nome do arquivo antes da extensão. Caso o valor do campo especificado seja "uva", o nome do arquivo resultante será .\dados\imagens\uva.png
     • Substituir o caminho inteiro pelo campo: o conteúdo do campo especificado é usado como diretório de local, nome de arquivo e extensão. Caso o valor do campo especificado seja C:\Temp\arcos-íris_e_unicórnios.jpg, o nome do arquivo resultante será C:\Temp\arcos-íris_e_unicórnios.jpg.
   • Usando este campo: use o menu suspenso para selecionar o campo de entrada que contém os dados para modificar o nome do arquivo.
4. Interromper e gerar erro se um arquivo não for encontrado: quando essa opção está marcada, o Alteryx gera um erro caso o arquivo não seja localizado. A mensagem de erro é Não é possível acessar o arquivo: (caminho).

Configuração da ferramenta para entrada ou passagem

1. Especifique o nome do arquivo que contém o blob a ser lido. Todos os tipos de arquivos são compatíveis.
2. Opções de blob: fornece opções para processar arquivos grandes.
   • Dividir blobs em partes: quando essa opção está marcada, os blobs são divididos em blobs menores, ou "partes", e enviados para as etapas posteriores como registros individuais. Cada registro contém esse blob e também um campo adicional chamado "BlobNumber", que é o número de sequência de cada parte. O primeiro é o 1, o segundo é o 2, etc.
   • Tamanho máximo das partes: permite especificar o tamanho (KB) de cada parte criada. Caso o blob original não seja um múltiplo exato do tamanho da parte, a parte final ficará abaixo do tamanho especificado. Caso o blob original seja menor que o tamanho da parte, ele é gerado como um blob único, mas ainda apresenta o campo "BlobNumber".

Não tenho a certeza de quanto de um exemplo do "mundo real" isto é, mas tenho actualmente uma aplicação lá fora que guarda detalhes para um jogo de cartas de negociação, incluindo as imagens para as cartas. Dado que a contagem de registros para o banco de dados é de apenas 2851 registros até à data, mas dado o fato de que certas cartas foram lançadas várias vezes e têm obras de arte alternativas, foi realmente mais eficiente em termos de tamanho para digitalizar o "quadrado primário" da arte e, em seguida, dinamicamente gerar a fronteira e efeitos diversos para o cartão quando solicitado.

O criador original desta biblioteca de imagens criou uma classe de acesso de dados que torna a imagem baseada no pedido, e fá-lo muito rapidamente para visualização e cartão individual.

Isto também facilita a Implementação / Actualizações quando são lançados novos cartões, em vez de fechar uma pasta inteira de imagens e enviá-los para o cano e garantir que a estrutura de pastas adequada é criada, eu simplesmente actualizo a base de dados e tenho o utilizador faz o download outra vez. Isso atualmente tem um tamanho de até 56MB, o que não é ótimo, mas eu estou trabalhando em um recurso de atualização incremental para futuros lançamentos. Além disso, há uma versão "no images" da aplicação que permite que aqueles over dial-up para obter a aplicação sem o atraso de download.

Esta solução tem funcionado muito bem até à data, uma vez que a aplicação em si é orientada como uma única instância no ambiente de trabalho. Há um site onde todos estes dados são arquivados para acesso on-line, mas eu não utilizaria, de modo algum, a mesma solução para este problema. Concordo que o acesso aos ficheiros seria preferível, porque melhoraria a frequência e o volume dos pedidos que estão a ser feitos para as imagens.

Espero que isto não seja muito tagarelar, mas eu vi o tópico e queria fornecer alguns meus insights de uma aplicação de pequena e média escala relativamente bem sucedida.

Por Eduardo Legatti

Olá,

No artigo anterior, eu demonstrei através de exemplos práticos, não só como gerar arquivos externos ao banco de dados, mas também como ler o conteúdo dos mesmos através da package UTL_FILE. Foi demonstrado também um exemplo prático de como carregar arquivos binários para colunas do tipo da dado BLOB em tabelas de banco dados, através do uso da package DBMS_LOB. Bom, o objetivo deste artigo será o de demonstrar a operação inversa, ou seja, demonstrar como salvar o conteúdo de um campo BLOB para um arquivo em disco. Para realizar esta operação utilizarei uma stored procedure que chamarei de BLOB_TO_FILE. No mais, vamos aos exemplos práticos ...

Vale a pena salientar que para esta demonstração, utilizarei o mesmo objeto directory ARQUIVO_DIR que foi criado e discutido no artigo anterior.

Aproveitando também a estrutura criada e discutida no artigo anterior, irei carregar várias imagens (*.jpg) para a tabela TAB_IMAGEM fazendo uso da stored procedure CARREGA_IMAGEM, mas com algumas modificações que não vem ao caso. Para maiores detalhes sobre a stored procedure CARREGA_IMAGEM, acesse o artigo anterior.

Após realizados os procedimentos acima, a tabela TAB_IMAGEM ficou populada conforme demonstrado abaixo:

A questão agora é: Como fazer a operação inversa? Digo, como salvar estas imagens de volta para o disco? Bom, depois de algumas pesquisas em alguns sites, blogs, documentação da Oracle, além de realizar alguns ajustes e modificações em códigos PL/SQL aqui e outros ali, cheguei ao fim da criação de uma stored procedure genérica na qual chamei de BLOB_TO_FILE. Para realizar o download do código PL/SQL de criação da stored procedure, clique aqui.

• P_DIRETORIO - o nome do objeto directory a ser utilizado para destino dos arquivos que serão criados.
• P_TABELA - a tabela de banco de dados que contém a coluna BLOB.
• P_COL_NOME - a coluna que proverá um valor único para a geração do nome do arquivo a ser salvo em disco.
• P_COL_BLOB - a coluna do tipo de dado BLOB que contém o conteúdo binário que deverá ser salvo em disco.

No mais, irei executar abaixo a stored procedure BLOB_TO_FILE afim de criar os arquivos (*.jpg) no diretório definido pelo objeto directory ARQUIVO_DIR. Irei ativar o parâmetro SERVEROUTPUT do SQL*Plus para "ON" apenas para gerar uma saída de texto, enquanto os registros vão sendo processados pela stored procedure:

Ao finalizar a execução do procedimento BLOB_TO_FILE, poderemos ver abaixo os arquivos que foram criados no diretório "/tmp"

Abaixo, após abrir o arquivo imagem1.jpg e o arquivo imagem10.jpg em um editor ou visualizador de imagens, poderemos verificar que os mesmos foram salvos em disco de forma consistente, ou seja, são arquivos válidos sem qualquer corrupção em seus dados.