[MySql] Group By datum, ook als deze niet voorkomt

[Tijsje]

Ik wil met een query het aantal verkopen per dag ophalen en deze tonen in een grafiek.
Dit lukt wel, maar als er op een dag geen items verkocht zijn krijg ik ook geen datum met aantal terug en dit verpest natuurlijk heel mijn grafiek. Ik wil eigenlijk gewoon een datum met het getal 0 terug krijgen.
Is dit mogelijk binnen een mysql query?

[P_de_B]

Joinen met een tabel met alle datums erin?

[Woy]

Of gewoon afvangen in je presentatie laag

[Tijsje]

Op het moment vang ik het ook af binnen php, maar ik had het gevoel dat dit gewoon binnen mysql moest kunnen.
Aan een tabel met datums heb ik ook zitten denken, maar dit lijkt me nu ook niet de ideale oplossing.
Is er niks mogelijk met ADD_DATE / INTERVAL ?
Google geeft ook niet echt een resultaat waar ik iets mee kan.

[Woy]

Maar waarom zou je het met dergelijke kunstgrepen op willen lossen als het in je code niet veel meer is dan in een loopje kijken of een datum voorkomt?

[NMe]

Tijsje schreef op donderdag 16 december 2010 @ 15:10:
Op het moment vang ik het ook af binnen php, maar ik had het gevoel dat dit gewoon binnen mysql moest kunnen.

Databases zijn bedoeld voor data-opslag (heel gek ) en hebben niets te maken met je presentatie. Als je gekke toeren moet gaan uithalen om het in query's te gaan regelen, dan kun je het beter naar je code toe trekken.

[Gomez12]

NMe schreef op donderdag 16 december 2010 @ 15:14:
[...]

Databases zijn bedoeld voor data-opslag (heel gek ) en hebben niets te maken met je presentatie. Als je gekke toeren moet gaan uithalen om het in query's te gaan regelen, dan kun je het beter naar je code toe trekken.

Andersom kom je dit wel vaker tegen en is een join redelijk cheap.
Persoonlijk voeg ik ( zo goed als ) altijd gewoon 1 tabel toe met data en een admin control om jaar x daarin te vullen.

Theoretisch ben ik het eens met de stelling dat het in de presentatielaag thuishoort, maar daar heb ik veelal meerdere van en ik vind het persoonlijk ook niet extreem verkeerd om de data een beetje presentatie te geven als het alternatief is dat ik iets meerdere keren dubbel moet gaan maken.

Ik vind het geen business logica, ik vind het niet puur iets wat ik in elke view als logica wil hebben. Ik vind het verdedigbaar dat ik het onderdeel van de data maak. Het is niet alsof het onbekende data is, het is bekend het is enkel niet aanwezig.

[rewind.]

In je select:
DAYOFYEAR(table.created_at) as dagvanjaar

(created_at moet wel een datetime zijn)

en dan GROUP BY dagvanjaar


Je kunt het dan ook nog doen met WEEK of MONTH en andere mysql functies zoals hier beschreven:
http://dev.mysql.com/doc/...e-and-time-functions.html

[ Voor 68% gewijzigd door rewind. op 16-12-2010 21:18 ]

[Gomez12]

rewind. schreef op donderdag 16 december 2010 @ 21:14:
In je select:
DAYOFYEAR(table.created_at) as dagvanjaar

(created_at moet wel een datetime zijn)

en dan GROUP BY dagvanjaar

Wat moet dat doen?
Vult dat in een verkoopgrafiek de weekenden in op een nul (zodat je 7dagen in 1 grafiek hebt) of vult het enkel 1 datum in?

[glrfndl]

Volgens mij mis je dan alsnog de dagen waar geen verkopen geweest zijn? (ben niet meer zo thuis in mysql)

Een vrij gemakkelijke manier om het met een query op te lossen is met behulp van een nummer-tabel (in feite wat P_de_B in de eerste reactie al zegt). Een nummer tabel zou gewoon standaard in een nieuwe database aanwezig moeten zijn

[rewind.]

Stel je doet dit:

code:

SELECT 
rl_order.id,
COUNT(rl_order.id) AS ordercount,
rl_order.created_at,
DAYOFYEAR(rl_order.created_at) as dag
FROM rl_order 
WHERE rl_order.created_at BETWEEN 'beginvanweek' AND 'eindvanweek'
GROUP BY dag
ORDER BY dag ASC

dan heb je van iedere dag van die week het aantal orders.
bv:
dag: 250, ordercount: 59
dag: 251, ordercount: 60
dag: 252, ordercount: 85
dag: 253, ordercount: 59
dag: 254, ordercount: 59
etc.

je kunt DAYOFWEEK gebruiken om dagnummer van de week te krijgen. 1 = zondag etc.

verrek ik miste het 2e deel van de vraag. maar met dayofweek heb je dagnummers die je met PHP dan kunt opvangen.

[ Voor 17% gewijzigd door rewind. op 16-12-2010 21:53 ]

[Voutloos]

Nee, je mist vooral dat je niet een datum kan selecteren van rows die er niet zijn. Je hebt dus een suffe datum tabel erbij nodig als je het helemaal in 1 enkele query wil oplossen.

[Gomez12]

glrfndl schreef op donderdag 16 december 2010 @ 21:46:
Een nummer tabel zou gewoon standaard in een nieuwe database aanwezig moeten zijn

Tja, waar wil je dan ophouden? Als ik tijden wil tonen dan maar een standaard tijdstabel erin?
Als ik een oplopende reeks wil tonen dan maar een tabel tot aan max getal?
Jammer, maar helaas. Nu wil ik een kleurentabel hebben, die heb je dan weer niet...

Dit soort beslissingen kan een db-bouwer niet van te voren maken, er zijn te veel mogelijkheden en het zelf aanmaken is te makkelijk

[glrfndl]

Gomez12 schreef op donderdag 16 december 2010 @ 22:05:
[...]

Tja, waar wil je dan ophouden?

Bij 2^31 -1 als je een int gebruikt en anders bij 2^63 -1 als je een bigint gebruikt? (j/k ofcourse) Op zich zul je met een tabel van 100.000 nummers ofzo vaak wel toe kunnen, en anders plemp je er nog een paar bij. Doorgaan tot de max waarde van int of bigint is waarschijnlijk overdreven .

Als ik tijden wil tonen dan maar een standaard tijdstabel erin?
Als ik een oplopende reeks wil tonen dan maar een tabel tot aan max getal?
Jammer, maar helaas. Nu wil ik een kleurentabel hebben, die heb je dan weer niet...

Tijdstippen, tijdsintervallen en oplopende reeksen genereer je uit die numbers tabel, die maak je daar waarschijnlijk niet nog een keer apart voor aan. Hoe je kleuren genereert uit nummers weet ik niet (hoewel, nummertabel tot 16,7 miljoen? ), maar anders zou ik dat misschien ook nog wel eens doen

Dit soort beslissingen kan een db-bouwer niet van te voren maken, er zijn te veel mogelijkheden en het zelf aanmaken is te makkelijk

True, hence the smiley. Het is natuurlijk geen silver bullet voor alles, maar kan wel heel handig zijn. Een paar 100 kb spenderen voor zo'n tabel kan vaak de moeite waard zijn

[ Voor 6% gewijzigd door glrfndl op 16-12-2010 22:41 ]

[RobIII]

glrfndl schreef op donderdag 16 december 2010 @ 22:40:
Doorgaan tot de max waarde van int of bigint is waarschijnlijk overdreven

Überhaupt beginnen (als vendor) is overdreven

Ik meen overigens dat SQL 2008 (R2) iets van een Range(x,y) heeft ofzo die een range van x tot y teruggeeft; maar pin me d'r niet op vast. Ik zou 't moeten nakijken. Maar al zit 't er niet in, je zou natuurlijk altijd nog een UDF kunnen maken.

[ Voor 8% gewijzigd door RobIII op 16-12-2010 22:48 ]

[The Eagle]

Tuurlijk kan dat. Self join icm een ifnull() functie. Bij Oracle heet zo'n ding een NVL