Version imprimable
Bonjour,
Utiliser
Create Table #tmp ...
OU
Declare @tmp Table ...
J'aurais voulu savoir quelles sont les différences entre ces 2 méthodes ?
Je sais que l'une est permanente, donc ne pas oublier de la supprimer après le traitement et l'autre ne vit que pendant le traitement en cours.
Et comment faire le meilleur choix ?
Merci
La principale différence, c'est que :
J'ai dit une grosse connerie
NON !
#tmp est une table locale instanciée dans la tempdb (base de données systèmes des objets temporaire) mais permettant des contraintes avancées (CHECK, FOREIGN KEY...) et l'indexation
Elle persiste tant que l'utilisateur est connecté et sera détruite par un DROP TABLE ou la déconnexion de l'utilisateur.
@tmp est une variable table instanciée dans la tempdb, mais ne permet que la clef primaire (pas d'index ni d'autres contraintes).
Elle n'existe que dans la porté locale de code (pas de DROP...)
MAIS ... la cardinalité de @tmp est évaluée à 1 dans les plans de requêtes, tandis que celle de #tmp est évaluée de manière statistique !
Et cela change beaucoup de chose en matière de perf.
Autrement dit : une seule ligne (voire très peu) et peu de colonnes => @tmp.
Dans les autres cas :
- soit #tmp
- soit une table en dur dans la base avec un tag de données temporaires.
A +
Grmpf. Désolé !
Ça a toujours été ainsi ?
J'étais persuadé que sous SQL Server 2000 tout du moins, les tables temporaires étaient globale (???)
La différence globale/locale se fait entre une table # / ##
Soit elle est globale pour les session, soit uniquement pour la session locale.
La différence avec les @table est tout autre.
D'accord. Encore désolé, j'ai tout mélangé :cry:
Merci pour vos réponses, je me range ça dans un coin de ma tête !
:ccool:
Par contre c'est quoi et à quoi ça sert :
"soit une table en dur dans la base avec un tag de données temporaires."
En gros, c'est la même chose qu'une table temporaire, mais c'est bien une table en dur dans la base, avec en sus une colonne permettant de stocker un marqueur transactionnel (GUID par exemple).
On l'utilise de la façon suivante :
- générer une valeur de marqueur
- insérer des lignes avec ce marqueur
- faire des requêtes en filtrant sur ce marqueur
Cela évite l'utilisation de tables temporaires dont les performances sont généralement moins bonnes du fait des changements de schémas.
A +
J'ajoute, qu'il est impossible de faire les opération suivantes avec une variable table :
- ROLLBACK dans une transaction avec une variable table (@table)
- ALTER sur une variable table (@table)
- directement du SQL dynamique avec une variable table (@table)
Par contre la variable table (@table) est très utile pour les UDFs retournant une table
Je me suis posé la même question il y a un moment
A+
Un grand Merci !:mrgreen: