Bonjour,
 
J'ai une table "table" dans laquelle j'ai un certain nombre d'enregistrements par jour (champ "date" ).
Il y a certains jours pour lequel il n'y a pas d'enregistrements correspondants. Exemple :
 
01.01.06 x
01.01.06 y
01.01.06 z
02.01.06 t
04.01.06 a
05.01.06 b
 
Si je fais une requête du style : SELECT `date`, count(*) AS total FROM `table` GROUP BY `date` j'obtiens :
 
01.01.06 2
02.01.06 1
04.01.06 1
05.01.06 1
...
 
Et là je constate que j'ai plein de trous aux dates pour lesquels il n'y a pas eu d'enregistrements.
Comment faire simplement une requête qui me renvoie tous les jours sans modifier la structure de ma table ?
Exemple de ce que je veux avoir :
 
01.01.06 2
02.01.06 1
04.01.06 0
04.01.06 1
05.01.06 1
...
 
Bonne journée

a mon avis c 'est pas possible (mais je suis peux me tromper) a part en creant une autre table "jours" contenant tous les jours possibles et en faisant une requete du style

Je suis d'accord pour la table "jours" ( tu as un exemple la mais pourquoi faire un sous-select???
Genre  

oui tu as raison le sous-select n est pas obligatoire
c'est un mauvais reflexe que j ai pris

 
Et elle contient quoi, votre table "jours" ? Tous les jours possibles ? C'est inélégant et limitif, sans parler de l'impact possible sur les perfs.  C'est de la triche car ça ne peut marcher qu'avec des cas finis. C'est une technique peu généralisable.
 
Si on voulait ne serait-ce que rajouter les heures et les minutes et sélectionner un intervalle, ça serait insupportable.
 
Il vaut mieux accepter que ce traitement ne colle pas au SQL et coder un peu de logique par-dessus, ne serait-ce qu'avec une stored procedure.

bah perso je cherchait pas a etre particulierement elegant mais a repondre en SQL a un probleme SQL

C'est certain que dans ce cas précis, il est possible d'y répondre en SQL, en faisant une pirouette.
 
Mais je ne pense pas que ce soit souhaitable.

sircam > ça se fait assez souvent ce genre de bidule, notamment dans les schémas de type décisionnel. La table de tous les jours (le calendrier) permet par exemple d'exploiter les index et au final d'améliorer les perfs par rapport à une stored procédure.
 
Effectivement, il faut que la problématique soit un cas discret. Pour son problème c'est le cas.

En fait la solution de créer une table à côté ne me convient pas trop car je ne connais pas à l'avance les deux dates minimales et maximales de ma sélection.
Celles-ci peuvent être choisies par l'utilisateur (dates passées et dates futures).
N'est-il pas possible de créer en mémoire une sorte de table avec ces dates juste pour la requête SQL ? D'un point de vue taille mémoire, le nombre de jours ne dépasse pas 2 mois.

ben, c'est simple, tu crées une table temporaire avec les jours de l'interval saisie par ton user

sircam > à la base, c'est pas au SGBD de divaguer à propos de données qui n'existent pas.
donc ce que tu demandes, à moins de faire la pirouette stipulée, y'a pas moyen.
 
tu peux toujours passer par une PS qui va te générer un curseur allimenté en fonction d'une date de début, une date de fin, et qui rempli en fonction des nombres de jours par mois et tenant compte des années bisextilles, mais ça ne changera rien au schmilblick : c'est gore, et c'est pas au sgbd se s'en occuper.

Arjuna> Mais c'est justement ce que je ne veux pas.
 
La stored proc, c'était à l'extrême limite si on n'a pas de couche par dessus, dans le cas où l'intervalle n'est pas assez discret (ou pas discret du tout).
 
Et inversément, créer une table avec des jours, si besoin au vol, dans le seul but que ça colle au DBMS, c'est assez tordu, alors que le traitement n'a clairement pas sa place au sein du DBMS.

c'est bien ce que je te dis vin dieu
 
tu fais ton select avec tes jours qui existent uniquement.
 
et après, dans ton appli qui appelle la requête, tu t'occupes de boucher les trous. c'est pas au sgbd de le faire. ou alors tu viens pas te plaindre parceque c'est pas propre.

Mais bourdel, c'est ce que je me tue à répéter.
 
http://forum.hardware.fr/hardwaref [...] m#t1417420