[MySQL] Query met alle maanden van het jaar

[-FoX-]

Ik zou graag een query hebben die alle data voor een jaar ophaalt, ook voor maanden waar geen data voor is. Voorlopig heb ik het opgelost door de lege maanden in de code op te vullen. Maar ik had toch graag geweten of het rechtstreeks vanuit een query kan:

Dit is de query die ik nu heb:

SQL:

SELECT SUM(amount) as amount, 
    MONTH(order_date) as month, 
    order_date, 
    currency 
FROM orders
    GROUP BY month 
    HAVING YEAR(order_date) = 2008;

Ik wil enkel de resultaten voor een bepaald jaar tonen, daarvoor moet ik deze order_date wel expliciet in de SELECT clause opnemen? Of kan het ook zonder?

[whoami]

Maak een 'dummy' tabel met daarin alle maanden, en OUTER JOIN op die tabel.
/voorzet.

[ Voor 6% gewijzigd door whoami op 17-09-2008 16:15 ]

[-FoX-]

Mja, dat is idd een optie maar geen goede; dan vul ik het liever verder aan in de code
Ik dacht er misschien ook te komen door gebruik te maken van de database DATE functies, maar tot dusver geen succes

[Voutloos]

Waarom is dat geen goede optie? Jij wl een outer join met wat meta data, en helaas moet je eerst eenmalig voorkauwen welke maanden er zijn. Appeltje eitje.

[glashio]

/neemt aan

SQL:

SELECT
    SUM(i.amount) as amount, 
    months.no AS `month`,
    i.order_date,
    i.currency 
FROM
    (
        SELECT 1 as no
    UNION
        SELECT 2
    UNION
        SELECT 3
    UNION
        SELECT 4
    UNION
        SELECT 5
    UNION
        SELECT 6
    UNION
        SELECT 7
    UNION
        SELECT 8
    UNION
        SELECT 9
    UNION
        SELECT 10
    UNION
        SELECT 11
    UNION
        SELECT 12
    ) months
LEFT JOIN
    invoice i
ON
    (
        months.no = MONTH(i.order_date)
    AND
        YEAR(i.order_date) = 2008
    )
GROUP BY months.no

[justmental]

Andere opmerking:
Having wordt na de group by uitgevoerd.
Daar filteren op jaar is niet handig, dat kan beter in de where.

[-FoX-]

Die union is wel geniaal ja Dat ik daar niet aan gedacht heb...
Maar puur op basis van een sysdate is geen oplossing mogelijk, lijkt me dan?

[RobIII]

-FoX- schreef op woensdag 17 september 2008 @ 16:46:
Die union is wel geniaal ja Dat ik daar niet aan gedacht heb...

en dat vind je mooier dan whoami's oplossing?

[-FoX-]

RobIII schreef op woensdag 17 september 2008 @ 17:26:
[...]

en dat vind je mooier dan whoami's oplossing?

Mja, ik heb nog nooit een maand weten bijkomen, jij wel?

[Creepy]

offtopic:
October... de oct staat voor 8... raad eens wat er wel eens is veranderd.....

Serieus: je vind de union oplossing daadwerkelijk mooier/beter/handiger dan de join?

[Voutloos]

Gewoon dus een tabel voor maanden maken. Iedereen snapt de inhoud van die tabel en je queries blijven lekker helder.

Voor statistieken is het soms handig als je al standaard over een dagen en/of maanden dataset kon beschikken, maar then again, het is ook in 10 seconden zelf gemaakt.

[Gomez12]

Of je laat je code de unions genereren voordat je de query doorzet naar je dbase. Dan kan je in je code wel de sysdates gebruiken ( voor maanden niet zo relevant, maar bij weeknrs / dagen per maand kan dit nog wel eens relevant zijn )

Gaat het echt alleen om maanden dan zou ik het tabelletje ernaast maken, wil je kunnen erin kunnen duiken naar weken / weekdagen / dagen van de maand gaan dan zou ik in code die union opbouwen. Een complete tabel van de laatste 10 jaar opbouwen met dagen en weeknrs lijkt me niet meer zo zinnig ( en zo af en toe wil ik wel eens weten hoeveel bezoekers er op elke zondag zijn geweest )

[Voutloos]

Ik heb wel eens voor een bepaalde statistiek een tabel met een tiental jaren aan datums gebruikt. En dat was gegarandeerd veel minder werk dan een andere aanpak, en die tabel van enkele KB's paste gelukkig ook nog net aan op de db.
Overigens kan je prima alsnog een where clause op 'zondag' zetten en zodoende nog steeds de zondagen opnemen waar geen data voor is.

Ik denk graag in sets data (imo ook aanbevolen gedachtengang bij queries ) en dan is de set maanden tegen de set logs outer joinen gewoon een heel logische gedachten gang...