Nosso time começou a desenvolver uma tarefa que tinha como intenção inicial corrigir uma grid, na qual uma coluna não aparecia o dado referente a preço fidelidade. Após o planejamento com o PO (Product owner) notamos que na verdade a reclamação do cliente era indevida pois os preços fidelidades estavam sendo exibidos na tela. Na verdade o cliente esperava ver na tela os campos referentes ao preço de oferta fidelidade.

Começamos a adicionar na grid os campos solicitados e ao entrar no método nos deparamos com um problema, quando rodamos a query no banco de dados a query não retornou nenhum dado, mesmo mudando alguns parâmetros no where.

A query que realizava o select no banco era muito grande,  resolvemos então realizar selects nas tabelas separadamente, tendo em vista que algumas tabelas estavam vazias entendemos o motivo da query não retornar nenhum valor.

O estranho foi que na aplicação a query retorna os valores e executando diretamente no banco não trazia nenhum dado. Resolvemos fazer um debug no método novamente e notamos que na primeira linha ele chamava outro método que tem como função inserir vários dados nas tabelas vazias.

Chegamos a conclusão que essas tabelas são tabelas temporárias, essas tabelas são muito utilizadas para manipulações de um grande conjunto de dados recuperados do banco de dados, onde esses dados são restritos por transações e são excluídos automaticamente quando a transação termina. Vários usuários podem acessar a mesma tabela e estarem visualizando dados diferentes sem uma transação interferir na outra. Um outro motivo que leva a utilização das tabelas temporárias é a limitação existente na cláusula in em um where, onde é possível recuperar somente mil tuplas, com a tabela temporária podemos fazer um join por exemplo e solucionar isso.

Ao olhar a configuração da tabela no banco notamos que existe um campo chamado duration que pode ser de dois tipos SYS$SESSION, SYS$TRANSACTION ou nula. Na tabela que estávamos trabalhando ela estava com o  SYS$TRANSACTION, onde os dados são excluídos após o commit. O tipo SYS$SESSION os dados são preservados durante a transação, por padrão as tabelas temporárias são criadas com duration SYS$TRANSACTION.

Exemplo de criação de tabela temporária SYS$TRANSACTION:

CREATE GLOBAL TEMPORARY TABLE tabela_temp_da_camila (

   “KEYI1”   NUMBER,

   “KEYI2”   VARCHAR2(400 CHAR),

   “KEYI3”   DATE

) ON COMMIT DELETE ROWS;

Exemplo de criação de tabela temporária SYS$SESSION:

CREATE GLOBAL TEMPORARY TABLE tabela_temp_da_camila (

   “KEYI1”   NUMBER,

   “KEYI2”   VARCHAR2(400 CHAR),

   “KEYI3”   DATE

)  ON COMMIT PRESERVE ROWS;

A forma como o Oracle cria e lida com as tabelas temporárias é diferente em outros bancos de dados, como por exemplo o SQLServer (https://www.devmedia.com.br/tabelas-temporarias-no-sql-server/2610) que exclui também a estrutura da tabela, isso pode fazer com que um desenvolvedor que já trabalhou com outro banco de dados e não conheça o Oracle não identifique logo no princípio que se trata de uma tabela temporária.

Referências:

https://www.devmedia.com.br/tabelas-temporarias-no-banco-de-dados-oracle/1915
https://www.devmedia.com.br/tabelas-temporarias-no-sql-server/2610
https://docs.oracle.com/cd/B19306_01/server.102/b14237/statviews_2105.htm#REFRN20286
https://docs.oracle.com/cd/B19306_01/server.102/b14200/statements_7002.htm#sthref7482
https://stackoverflow.com/questions/5017641/duration-of-data-in-a-global-temporary-table
https://stackoverflow.com/questions/400255/how-to-put-more-than-1000-values-into-an-oracle-in-clause
Autor

Camila Ferreira é desenvolvedora na Bluesoft há mais de um ano. Ela participou do programa Padawan (Movimento Codar), onde aprendeu todas as tecnologias disponíveis para que pudesse atuar com o software da Bluesoft.

Deixe aqui o seu comentário