Dois-je valider ou annuler une transaction qui crée une table temporaire, la lit, puis la supprime?

Question

Pour sélectionner des informations relatives à une liste de centaines d'ID ... plutôt que de faire une énorme déclaration, je crée une table temporaire, y insère les ID, la joint avec une table pour sélectionner les lignes correspondant aux identifiants, puis supprime la table de temp. Il s'agit donc essentiellement d'une opération de lecture, sans modifications permanentes apportées aux tables de base de données persistantes.

Je fais ceci dans une transaction, pour m'assurer que la table temporaire est supprimée quand j'ai fini. Ma question est la suivante: que se passe-t-il lorsque je commets une telle transaction par rapport à une transaction? En termes de performances ... le moteur de base de données doit-il faire plus de travail pour annuler la transaction en la validant? Y at-il même une différence puisque les seules modifications sont faites à une table de temp?

question connexe, mais ne répond pas à mon cas spécifique impliquant des tables temporaires: Should I commit or rollback a read transaction?

EDIT (clarification de la question):

Pas la recherche de conseils à point de commettre/rollback. La transaction est absolument nécessaire. Supposons qu'aucune erreur ne se produit. Supposons que j'ai créé une table temporaire, supposons que je sais que l'écriture réelle sur tempdb s'est produite, supposons que j'effectue des opérations en lecture seule (sélection) dans la transaction et supposons que j'émets une instruction delete sur la table temporaire. Après tout ça ... qui est moins cher, commit ou rollback, et pourquoi? Quel autre travail le moteur db peut-il faire à THAT POINT pour un commit contre une restauration, basé sur ce scénario spécifique impliquant des tables temporaires et des opérations en lecture seule?

Answer 1

Si nous parlons de table temporaire locale (c'est-à-dire que le nom est précédé d'un seul #), au moment où vous fermez votre connexion, SQL Server supprimera la table. Ainsi, en supposant que votre couche de données soit bien conçue pour garder les connexions aussi courtes que possible, je ne m'inquiéterais pas de la création de tables temporaires dans une transaction. Je suppose qu'il pourrait y avoir une légère différence de performance d'emballage de la table dans une transaction, mais je parie qu'il est si petit qu'il est sans importance par rapport au coût de garder une transaction ouverte plus longtemps en raison du temps de créer et de remplir la table de temp.

Answer 2

Une manière plus simple de s'assurer que la table temporaire est supprimée est de la créer en utilisant le signe #.

CREATE TABLE #mytable ( rowID int, rowName char (30))

Le # indique SQL Server que cette table est une table temporaire locale. Cette table est uniquement visible pour cette session de SQL Server. Lorsque la session est fermée, la table sera automatiquement supprimée. Vous pouvez traiter cette table comme n'importe quelle autre table, à quelques exceptions près. Le seul vrai majeur est que vous ne pouvez pas avoir de contraintes de clé étrangère sur une table temporaire. Les autres sont couverts dans la documentation en ligne.

Les tables temporaires sont créées dans tempdb.

Si vous faites cela, vous n'aurez pas à l'emballer dans une transaction.