Discussion :

[Franck_P]

Bonjour,

J'ai une table d'objectif pour un indicateur donné. Exemple :

IdObjectif date_debut valeur
obj1 01/01/2008 120.000
obj2 01/06/2008 125.000
obj3 01/09/2008 90.000

Je voudrais pourvoir obtenir un jeu de donné du style (analyse mensuel)

Anne mois valeurObj
2008 01 120.000
2008 02 120.000
2008 03 120.000
2008 04 120.000
2008 05 120.000
2008 06 125.000
2008 07 125.000
2008 08 125.000
2008 09 90.000
2008 10 90.000
...
2009 01 90.000
...
2009 09 90.000


Comment faire cela facilement dans une requete ?

Merci

Franck

[CinePhil]

Si vous voulez afficher chaque jour, même s'il n'y a pas d'objectif en face, il vous faut une table de calendrier et faire une jointure dessus.
Voir au sujet du traitement des dates l'article de SQLPro.

[al1_24]

Tu cherches donc à créer des informations que tu n'as pas...
SQL a un peu de mal avec ce genre de démarche
Donc, dans un premier temps, il va te falloir une table de type calendrier qui te liste tous les mois, de manière à avoir une ligne pour chaque mois que tu n'as pas dans tes données.

Reviens vers nous avec la requête que tu auras construite, nous t'aiderons à la mettre au point.

[pacmann]

Salut !

Vous êtes un peu trop stricts les gars, et pas très imaginatifs !

C'est quoi ton SGBD ?

Ce truc là, je l'ai vu quelque part...

Ici :

http://www.waldar.org/blog/200908/ts...-recursive-cte

Et si tu comprends pas, Waldar se fera un plaisir de t'expliquer, je pense.

[SQLpro]

Sauf qu'en terme de performances, c'est particulièrement catastrophique de générer des données à la volée par récursivité !!!!

A +

[Waldar]

Sauf qu'en terme de performances, c'est particulièrement catastrophique de générer des données à la volée par récursivité !!!!

Oui et non, c'est vraiment une question de volumétrie.
Un calendrier reste une table de faible volumétrie (200 ans = 73050 lignes).
Sous Oracle sur une bonne machine, ça prend 16 ms.
Sous SQL Server, avec la limite de récursivité à 32767 c'est un peu plus long mais ça reste quand même très rapide.

Par contre je ne reviens pas sur le fait qu'une table calendrier est absolument nécessaire, c'est la meilleure solution.

[SQLpro]

16 ms. est pour moi un temps totalement rédhibitoire pour une requête simple. Imagine cette requête 10 000 fois pas jour => 160 secondes => 2 minutes et 40" par jours et sur 5 ans : 30 heures de process pour pas grand chose !

Cela s'appelle l'optimisation !

A +

[Waldar]

C'est exactement le même temps qu'un select sur la table calendrier (les 16 ms incluent le temps du message réseau).

Mais je reste d'accord sur le fond, ce genre de requête sert pour dépanner ou prouver des choses sur un environnement d'intégration (comme l'intérêt d'une table calendrier par exemple), certainement pas pour être executé plusieurs milliers de fois par jour en prod.