O desenvolvedor de C # incentivado pelo gerenciamento a escrever procedimentos armazenados do SQL Server geralmente produz procedimentos como este
create table #t1 (...);
insert into #t1 Select ... from table_a where ...;
insert into #t1 Select ... from table_b where ...;
update #t1 Set ... = ... where ...
Select * from #t1;
A declaração única é bastante simples e esse método faz com que produzam resultados corretos.
Muitas vezes, minha tarefa é migrar esses procedimentos para o Oracle.
Vamos enfrentar os seguintes fatos.
- Para diferentes tabelas temporárias no SQL Server são completamente independentes e podem ter qualquer estrutura ad hoc.
- As tabelas comuns globais da Oracle são objetos globais e todos os usos compartilham a mesma estrutura de tabela. Modificar essa estrutura é impossível, enquanto é usado em qualquer lugar.
Uma das coisas que aprendi com um dba Oracle foi evitar o uso de tabelas temporárias sempre que possível. Até o desempenho no servidor SQL se beneficia dessas modificações.
Substitua as inserções individuais por uniões
No caso mais simples, o acima pode ser transformado em algo como
select case when ... then ... end, ... from table_a where ...
union
select case when ... then ... end, ... from table_b where ...
Order by ...;
Uso de funções
As funções escalares e as funções com valor de tabela podem ajudar a transformar seu procedimento em uma única consulta do formulário acima.
Expressões de tabela comuns, também conhecidas como Subquery Factoring
O Subquery Factoring é quase o melhor que a Oracle oferece para evitar tabelas temporárias. Usando isso, a migração do SQL Server para Oracle é novamente bastante fácil. Isso requer o SQL Server 2005 e superior.
Essas modificações aprimoram a versão do SQL Server e, em muitos casos, facilitam a migração. Em outros casos, o recurso a tabelas temporárias globais torna possível a migração em um tempo limitado, mas é menos satisfatório.
Existem outras maneiras de evitar o uso de tabelas temporárias globais no Oracle?