Discussion :

[rad_hass]

Bonjour à tous,

J'ai vu qu'il était déconseillé dans le mesure du possible d'utiliser les Table temporaire, cependant est ce que ça peut se justifier ? Et à quel prix ?

Si on se trouve avec un nombre important de condition qui serait difficile à modéliser dans une requête simple ... Est ce un choix satisfaisant ?

Bien sûre que ça dépends beaucoup des cas d'utilisations et des attentes, mais y a t il des pratiques, critères qui permette un arbitrage ? (Ca peut être des méthodologie, des études ... ect).

De façon générale un DBA quand il voit une requête avec une Table Temporaire (construite avec des Union's ...) et quand il voit qu'il y a des Delete's sur la table temporaire.
Et qu'enfin il y est d'autres critères dans un Select finale, que se dit il ?

1 - Ce n'est pas acceptable, y a forcément mieux à faire ?
2 - Peut être qu'il est intéressent de faire un test sur les temps de réponse ?
3 - Une grande complexité du métier peut justifier cela ?

Ou la pire des réponses :

4 - Si on en arrive à écrire de telles requêtes, il y a forcément une mauvaise étude/conception ?


Je m'excuse si ma question est un peu trop général, mais c'est surtout les bonnes pratiques que je cherche à connaitre dans un tel cas.

Si vous me dites qu'il est impossible de répondre sans exemple claire, j'essaierai d'en faire un.

Merci de m'avoir lu et au plaisir de lire vos réponses.

[ylarvor]

Je dirais que selon le cas, si c'est un développeur débutant qui a écrit, il est possible d'être dans le cas 1.
Il m'est arrivé également de me trouver dans le cas 3 avec un modéle en 3 eme forme normal.

[SQLpro]

Commencez par lire l'article que j'ai écrit à ce sujet :
http://blog.developpez.com/sqlpro?ti...et_persistance

J'ai vu qu'il était déconseillé dans le mesure du possible d'utiliser les Table temporaire, cependant est ce que ça peut se justifier ? Et à quel prix ?

Une différence dans le pire des cas d'un facteur 1000. Est-ce suffisant ??? L'explication est dans le lien ci avant...

Si on se trouve avec un nombre important de condition qui serait difficile à modéliser dans une requête simple ... Est ce un choix satisfaisant ?

Jamais ! Sauf si votre ambition est sciemment de pourrir les performances de votre système.

Bien sûre que ça dépends beaucoup des cas d'utilisations et des attentes, mais y a t il des pratiques, critères qui permette un arbitrage ? (Ca peut être des méthodologie, des études ... ect).

Oui il y a un simple état de l'art contre un coût. Si le développeur va mettre 6 jours à écrire la requête alors qu'avec une série de 3 tables temporaire il mettra 4h, alors la balance est à étudier... Mais il y a fort à parier qu'il faudra y revenir par la suite !

De façon générale un DBA quand il voit une requête avec une Table Temporaire (construite avec des Union's ...) et quand il voit qu'il y a des Delete's sur la table temporaire.
Et qu'enfin il y est d'autres critères dans un Select finale, que se dit il ?

Que le niveau de connaissance en SQL de celui qui a écrit cela le rend incompétent à développer des applications bases de données. C'est en tout cas ce que je dit dans mes audits. Ce qui signifie qu'il faut former ces développeurs.

1 - Ce n'est pas acceptable, y a forcément mieux à faire ?

Oui

2 - Peut être qu'il est intéressent de faire un test sur les temps de réponse ?

Non

3 - Une grande complexité du métier peut justifier cela ?

Balance entre cout et savoir.

Ou la pire des réponses :

4 - Si on en arrive à écrire de telles requêtes, il y a forcément une mauvaise étude/conception ?

C'est possible, mais pas toujours !

A +

[elsuket]

Bonjour,

Il est effectivement conseillé d'éviter autant que c'est possible l'utilisation de tables temporaires, quelles qu'elles soient (@, # ou ##).

Cela se justifie par la pose de verrous sur la base de données système TempDB, qui est un pilier du moteur de base de données (parce que SQL Server la sollicite pour beaucoup de tâches, outre les requêtes).

Ajoutez à cela les coûts en lectures disque (bien plus lentes que les accès en RAM), puisque vous accédez à d'autres fichiers de base de données.
Certains vont même jusqu'à créer des transactions sur des tables temporaires ...

Évidemment ce type de table est très pratique, mais ce que vos gagnerez à en créer est une maintenance supplémentaire.
Depuis SQL Server 2005, qui a introduit les CTE, il devient très rare d'avoir recours à une table temporaire.

Je préfère passer une journée sur une requête complexe que d'écrire la même requête en 10 minutes avec des tables temporaires, mais ce n'est pas l'avis de tout le monde ...
Plus on s'habitue à écrire des requêtes complexes sans tables temporaraires (ni curseurs), et plus on les écrit vite ...

@++

[rad_hass]

Merci beaucoup pour vos réponses c'est simple claire et efficace ...

D'une part vous me réconfortez dans ma pensée (pire encore je me rends compte que c'est plus terrible que ce que je croyais), d'autre part je me dis que ça va me donner du travail en plus, je vais faire une audite des requêtes et mettre tout cela en évol et optimisation ... Le problème est que moi je ne voulais pas utiliser les tables temporaires, mais non seulement c'était déjà utilisé un peu partout, mais en plus mon chef de projet technique me préconisait cette solution et me dissait qu'elle lui convenait ... Je seraismieux lui répondre la prochaine fois.

Par ailleurs, le lien sur lequel vous me redirigez SqlPro, c'est un billet dans votre blog, mais y a t il un article sur ce sujet ? Ou l'article dont vous me parliez était le billet (car je ne vois pas de lien)

merci encore

[elsuket]

Par ailleurs, le lien sur lequel vous me redirigez SqlPro, c'est un billet dans votre blog, mais y a t il un article sur ce sujet ? Ou l'article dont vous me parliez était le billet (car je ne vois pas de lien)

La dernière partie de la phrase est correcte

@++