Início / dba / Perguntas / 73514
Accepted
Akash
Asked: 2014-08-09 06:34:17 +0800 CST

Devo verificar a existência de tabelas temporárias em procedimentos armazenados?

  • 772

Existe algum caso extremo em que seria recomendado verificar explicitamente, descartar e criar tabelas temporárias no início de um procedimento armazenado, em vez de apenas criá-las?

Da mesma forma, há um caso em que eliminá-los explicitamente no final do procedimento armazenado é preferível a permitir que o SQL Server os limpe?

sql-server sql-server-2012

2 respostas

  1. Best Answer

    Ao verificar #tbl

    Não custa nada verificar a existência da tabela (e descartá-la se existir) no início do procedimento, mas depende de como você deseja lidar com esse cenário e, na maioria dos casos, não é possível que ela já exista de qualquer maneira (pelo menos se estivermos falando sobre a mesma tabela #temp definida nesse procedimento armazenado).

    Você verifica a existência de uma tabela usando:

    IF OBJECT_ID('tempdb..#tablename') IS NOT NULL

    Você não pode verificar tempdb.sys.tables porque o nome real é #tablename__________some hex code, e você não deve usar OBJECT_ID('...') > 0 devido a esse possível problema .

    Claro, há exceções. Dois que me vêm à mente:

    • se você chamar tudo #temp, ou #t, ou #x, é possível que essa tabela já exista de um escopo externo antes de chamar o procedimento. Você poderia argumentar que deveria simplesmente abandoná-lo e criar o seu novo nesse caso, mas também poderia argumentar que esta é uma condição de erro que você deseja conhecer - então talvez esteja tudo bem em CREATE TABLE #xfalhar.

    • na verdade, você pode querer usar uma tabela #temp criada em um escopo externo e apenas criar uma se ela não tiver sido definida nesse escopo externo. Isso é possível e eu uso essa técnica o tempo todo, mas geralmente apenas quando quero capturar dados de procedimentos do sistema que não consigo manipular facilmente (por exemplo sp_helptext, ). Então eu posso fazer isso:

      CREATE TABLE #x([Text] NVARCHAR(MAX));
GO
CREATE PROCEDURE dbo.myhelp @p SYSNAME
AS
  INSERT #x EXEC sp_helptext @p;
GO
EXEC dbo.myhelp N'dbo.myhelp'; -- inception
GO
SELECT [Text] FROM #x;

      Isso funciona mesmo que #xseja definido fora. Esse é um exemplo terrível porque prefiro usar sys.sql_modules, mas tenho certeza de que você entendeu e pode imaginar como pode fazer isso com seus próprios procedimentos.

    Em DROP TABLE #tbl;

    Eu acho que se você deve descartar tabelas #temp explicitamente no final do procedimento está muito em debate e, portanto, seria fechado como baseado principalmente em opinião; veja estas excelentes postagens de blog de Paul White , leia-as completamente e volte e formule uma pergunta específica se todas as suas não forem respondidas:

    • 7

  2. Acho que dependeria de como você está usando tabelas temporárias. Se SELECT INTOestiver sendo usado eu testaria antes e dropno final. Testar antes e descartar evitará problemas indesejados no caminho que podem ou não surgir, é apenas uma boa prática de código para mim.

    Se você estiver usando CREATE TABLEpara criar primeiro a tabela temporária, acho que faria a mesma coisa apenas por hábito e tentando manter um padrão de como desenvolvo procedimentos. Com isso, você provavelmente conseguiria apenas ter a instrução drop no final do procedimento, já viu o código feito apenas com drops no final.

    Se você estiver em uma equipe, ou mesmo se for só você, estabeleça um padrão e cumpra-o.

    • 2

relate perguntas