Tables temporaires locales et globales - Quand utiliser quoi?

J'ai un rapport qui sur l'exécution se connecte à la base de données avec le nom d'utilisateur my_report_user. Il peut y avoir plusieurs utilisateurs finaux du rapport. Et à chaque exécution une nouvelle connexion à la base de données sera faite avec my_report_user (il n'y a pas de regroupement de connexions)Tables temporaires locales et globales - Quand utiliser quoi?

J'ai un ensemble de résultats que je pense peut juste être créé une fois (peut être sur la première exécution du rapport) et d'autres exécutions de rapports peuvent simplement réutiliser ce genre de choses. Fondamentalement, chaque exécution de rapport doit vérifier si ce jeu de résultats (stocké en tant que table temporaire) existe ou non. S'il n'existe pas, créez ce jeu de résultats, sinon réutilisez ce qui est disponible. Dois-je utiliser local tables temporaires (#) ou global tables temporaires (##)?

Est-ce que quelqu'un a déjà essayé ce genre de choses et si oui, s'il vous plaît faites-moi savoir de quoi tout ce qui m'importe? (Presque rapport simultané, etc.) Le

EDIT: J'utilise Sql-Server 2005

Source

2009-10-20 peakit

Quelle version de SQL Server? Si 2005+, les CTE (et éventuellement les CTE récursifs) sont une autre option. Sans en savoir plus sur ce que vous devez faire avec eux, je recommande des tables temporaires locales plutôt que globales ... –

Hypothèse: que la table temporaire globale ne soit pas supprimée car des connexions existent toujours, à quel moment les données de cette table deviennent invalides? c'est-à-dire, qu'est-ce qui définit quand les données doivent absolument être rafraîchies pour éviter les mauvaises données dans les rapports? –

sql-server 2005. Etes-vous sûr que les tables temporaires locales me permettent la réutilisabilité. Je pensais que les tables temporaires locales ne permettent pas la réutilisation sur plusieurs exécutions de rapports. Que dites-vous maintenant en connaissant la version? – peakit

Si vous souhaitez mettre en cache les jeux de résultats résultat sous votre propre contrôle, alors vous ne pouvez pas utiliser tables temporaires, de toutes sortes. Vous devez utiliser des tables utilisateur ordinaires, stockées dans tempdb ou même avoir votre propre base de données de cache de résultats.

Les tables temporaires, bot #local et ## shared ont une durée de vie contrôlée par la ou les connexions. Si votre application se déconnecte, la table temporaire est supprimée et cela ne fonctionne pas bien avec ce que vous décrivez. Le vrai problème consistera à remplir ces ensembles de résultats en cache sans les mélanger (pour finir, les ensembles de résultats contenant des éléments en double provenant d'exécutions de rapports concourants que l'on croit être la première exécution).

À titre de remarque, SQL Server Reporting Services le fait d'ores et déjà. Vous pouvez mettre en cache et partager des ensembles de données, vous pouvez mettre en cache et partager des rapports, cela fonctionne déjà et a été testé pour vous.

Source

2009-10-20 17:50:44

"Le vrai problème sera de peupler ces jeux de résultats en mémoire cache sans les mélanger" Je suis également inquiet pour cette affaire. Merci pour l'aide, en passant. – peakit

Vous pouvez utiliser les verrous d'applications. Utilisez une ressource qui identifie le rapport que vous consultez, par exemple. "rapport des ventes nord-ouest fiscal octobre 2009", ou "rapport d'identification 42". 1. sp_getapplock 'partagé', 'session'. 2. vérifiez l'ensemble de données, s'il est présent, utilisez-le pour le rapport, puis relâchez le verrouillage de l'application et quittez. 3. Si ce n'est pas le cas, libérez l'application loc, récupérez-la X sp_getapplock 'exclusive', 'session'. 4. Vérifiez à nouveau si le rapport existe, sinon créez-le et utilisez-le, relâchez x lock et quittez. 5. Si le rapport existe après avoir acquis le verrou X, relâchez le verrou x, revenez à l'étape 1. –

J'apprécie votre connaissance. Mais il y a toujours des chances que le jeu de résultats soit effacé par le moteur (lorsqu'il n'y a pas de connexions actives à cette table ## temp). Cela annule mon but de mise en cache. Que dire? Bien que le mécanisme de verrouillage que vous avez donné puisse être bon pour résoudre la concurrence ... – peakit

Il semble que vous soyez en mode OLTP maintenant. Lire sur l'entreposage de base de données va certainement vous aider.

Source

2009-10-20 17:57:00

Je trouve que les tables #temp peuvent être utiles dans certains scénarios, mais pas comme une bonne pratique. Je n'ai pas encore trouvé une utilisation valide pour les tables temporaires ## temporaires, que ce soit dans mon propre travail, ou dans le travail de quelqu'un d'autre qui a écrit à leur sujet. Le seul cas auquel je peux penser est BCP ou un autre processus externe qui doit construire un magasin de données temporaire et ensuite le récupérer dans une étape ultérieure. Dans ce cas, je préférerais utiliser une table permanente avec une sorte de clé et un processus d'arrière-plan pour gérer le nettoyage.

Source

2009-10-20 18:55:55

Tables temporaires locales et globales - Quand utiliser quoi?

Répondre

Questions connexes