Vaut-il mieux utiliser une variable de type table (VT) ou une table
temporaire (TT)dans le code d'une procédure stockée ?
Je sais déjà que, contrairement aux TT:
* les tables statiques en jointure avec une VT sont correctement référencées
dans les dépendances de la p.s.
* les VT n'occasionnent pas de recompilations intempestives lors de
l'insertion de plus de 6 enregistrements, contrairement aux TT.
J'ai remarqué que les VT ne provoquent pas l'abandon du process d'affichage
du plan de requête dans SQL QueryBuilder , contrairement aux TT.
Alors, j'ai du mal à comprendre pourquoi on continue d'utiliser/préconiser
des TT au lieu de VT ? 8-{
De +, où est pris l'espace pour le stockage des données (les TT tapant, de
mémoire, sur le segment données de tempdb) ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Med Bouchenafa
Il est vrai que les tables de type variable ont tout pour plaire et notamment l'aspect non recompilation des procédures qui les hebergent. Ils ont cependant l'inconvénient de ne pas permettre l'indexage autre que CLUSTER, cela peut être un handicap certain pour certaines requêtes Ils ne permettent pas non plus la création de statistiques et cela est un autre handicap pour l'optimiseur En fait, les deux types de tables sont nécessaires et leur utilisation dépend du besoin. Des fois, on a vraiment pas le choix comme dans le cas d'un SELECT INTO ou il est impossible d'utiliser une variable table.
-- Bien cordialement Med Bouchenafa
"Jean-Yves" a écrit dans le message de news:
Bonjour,
Vaut-il mieux utiliser une variable de type table (VT) ou une table temporaire (TT)dans le code d'une procédure stockée ?
Je sais déjà que, contrairement aux TT: * les tables statiques en jointure avec une VT sont correctement référencées dans les dépendances de la p.s. * les VT n'occasionnent pas de recompilations intempestives lors de l'insertion de plus de 6 enregistrements, contrairement aux TT.
J'ai remarqué que les VT ne provoquent pas l'abandon du process d'affichage du plan de requête dans SQL QueryBuilder , contrairement aux TT.
Alors, j'ai du mal à comprendre pourquoi on continue d'utiliser/préconiser des TT au lieu de VT ? 8-{ De +, où est pris l'espace pour le stockage des données (les TT tapant, de mémoire, sur le segment données de tempdb) ?
Merci du coup de pouce. Jean-Yves AUGER
Il est vrai que les tables de type variable ont tout pour plaire et
notamment l'aspect non recompilation des procédures qui les hebergent.
Ils ont cependant l'inconvénient de ne pas permettre l'indexage autre que
CLUSTER, cela peut être un handicap certain pour certaines requêtes
Ils ne permettent pas non plus la création de statistiques et cela est un
autre handicap pour l'optimiseur
En fait, les deux types de tables sont nécessaires et leur utilisation
dépend du besoin.
Des fois, on a vraiment pas le choix comme dans le cas d'un SELECT INTO ou
il est impossible d'utiliser une variable table.
--
Bien cordialement
Med Bouchenafa
"Jean-Yves" <JeanYves@discussions.microsoft.com> a écrit dans le message de
news: 6E70C23A-5EA1-401E-86D7-BF27363FE216@microsoft.com...
Bonjour,
Vaut-il mieux utiliser une variable de type table (VT) ou une table
temporaire (TT)dans le code d'une procédure stockée ?
Je sais déjà que, contrairement aux TT:
* les tables statiques en jointure avec une VT sont correctement
référencées
dans les dépendances de la p.s.
* les VT n'occasionnent pas de recompilations intempestives lors de
l'insertion de plus de 6 enregistrements, contrairement aux TT.
J'ai remarqué que les VT ne provoquent pas l'abandon du process
d'affichage
du plan de requête dans SQL QueryBuilder , contrairement aux TT.
Alors, j'ai du mal à comprendre pourquoi on continue d'utiliser/préconiser
des TT au lieu de VT ? 8-{
De +, où est pris l'espace pour le stockage des données (les TT tapant, de
mémoire, sur le segment données de tempdb) ?
Il est vrai que les tables de type variable ont tout pour plaire et notamment l'aspect non recompilation des procédures qui les hebergent. Ils ont cependant l'inconvénient de ne pas permettre l'indexage autre que CLUSTER, cela peut être un handicap certain pour certaines requêtes Ils ne permettent pas non plus la création de statistiques et cela est un autre handicap pour l'optimiseur En fait, les deux types de tables sont nécessaires et leur utilisation dépend du besoin. Des fois, on a vraiment pas le choix comme dans le cas d'un SELECT INTO ou il est impossible d'utiliser une variable table.
-- Bien cordialement Med Bouchenafa
"Jean-Yves" a écrit dans le message de news:
Bonjour,
Vaut-il mieux utiliser une variable de type table (VT) ou une table temporaire (TT)dans le code d'une procédure stockée ?
Je sais déjà que, contrairement aux TT: * les tables statiques en jointure avec une VT sont correctement référencées dans les dépendances de la p.s. * les VT n'occasionnent pas de recompilations intempestives lors de l'insertion de plus de 6 enregistrements, contrairement aux TT.
J'ai remarqué que les VT ne provoquent pas l'abandon du process d'affichage du plan de requête dans SQL QueryBuilder , contrairement aux TT.
Alors, j'ai du mal à comprendre pourquoi on continue d'utiliser/préconiser des TT au lieu de VT ? 8-{ De +, où est pris l'espace pour le stockage des données (les TT tapant, de mémoire, sur le segment données de tempdb) ?
