[SQL]Totale maandelijkse inkomst per voorstelling
Een vriend van mij heeft een database structuur over voorstellingen. Hij moet nu een query voor elkaar krijgen die voor hem de totale maandelijkse inkomsten per voorstelling uitrekent.
Dit is de samenhang van alle tabellen:
De prijs verschilt ook nog eens per rang dus daar moet ook rekening mee worden gehouden en er moet dan, zoals hier boven al vermeldt, per voorstelling een maandelijkse inkomsten bedrag uit komen.
We zijn er beiden nog niet uitgekomen en hoopten dat er een paar knappe koppen hier wat meer verstand van zaken heeft.
Gesponsorde koppelingen:
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
SELECT
v.titel, SUM(p.prijs)
FROM
voorstelling v, prijzen p
WHERE
v.titel = p.voorstelling
GROUP BY
v.titel
v.titel, SUM(p.prijs)
FROM
voorstelling v, prijzen p
WHERE
v.titel = p.voorstelling
GROUP BY
v.titel
En dan nog per maand.
Gewijzigd op 01/01/1970 01:00:00 door Martijn B
Verder mis ik nog redelijk wat id's in het model. Er wordt nu regelmatig gebruik gemaakt van strings als foreign keys (rang vs rangnaam, zaal vs zaalnaam). Hoewel het niet per definitie fout is, is het zeker niet aan te raden. Je database wordt er namelijk onnodig veel trager door.
Verder neem ik aan dat er ook kaarten aan de deur verkocht kunnen worden. Hoe zitten die gegevens in dit model verwerkt? En hebben mensen met een reservering per definitie ook betaald?
Dat zijn vragen die je je eerst moet stellen voordat je pas een zinnig woord kunt zeggen over de inkomsten per voorstelling per maand.
ps.
@Martijn: dat is te eenvoudig. Zie mijn commentaar.
@Klaasjan: als de prijs per rang vastgelegd wordt toch wel?
Gewijzigd op 01/01/1970 01:00:00 door Joren de Wit
Was meer bedoelt als een opzetje.
Gewijzigd op 01/01/1970 01:00:00 door Martijn B
Tip: Hoe de boel nog eens heel goed tegen het licht of begin even met een schone lei. Dat wil nog wel eens nieuwe/betere inzichten opleveren.
Michiel schreef op 14.01.2008 20:01:
Je bedoelt dat het datamodel zo in de opdracht vastgelegd is? Wat een baggeropdracht dan...Blanche, aangezien dit een school opdracht is, is er weinig te vertellen over de structuur van de database. Dit valt niet uit te kiezen.
Maar goed, dan moet je je alsnog die ene belangrijke vraag stellen: wanneer valt iets onder inkomsten, ofwel: wanneer is iets betaald?
Ik zou me er eigenlijk niet aan durven wagen om hier een query voor op te stellen, gewoonweg omdat het resultaat te allen tijde onbetrouwbaar is...
Michiel schreef op 14.01.2008 20:01:
Een slimme opmerking over een fout datamodel kan echter geen kwaad. Of leer jij soms ook dat 1 + 1 = 0.5 ? Ik mag toch hopen van niet.Blanche, aangezien dit een school opdracht is, is er weinig te vertellen over de structuur van de database. Dit valt niet uit te kiezen.
Ik heb op het HBO ook een soort gelijke opdracht gehad met een heel fout datamodel. Dat leverde erg interessante query's op.
Het gaat er om hoe het nu juist niet moet, en daar leer je weer van ;P
Gewijzigd op 01/01/1970 01:00:00 door Martijn B
Martijn! schreef op 14.01.2008 20:14:
En dan is het enige juiste antwoord op dit vraagstuk dus: 'Ik kan hier geen query voor opstellen, want het datamodel is incorrect!'Het gaat er om hoe het nu juist niet moet, en daar leer je weer van ;P
:P
ps. Bij deze toestemming gegeven om mijn reacties direct voor te leggen aan de betreffende docent. Kleine voorwaarde: ik wil dan wel het antwoord daarop weten :-)
Martijn! schreef op 14.01.2008 20:14:
Wanneer je niet kunt controleren of het antwoord correct is, is er niets interessants aan de query.@Frank:
Ik heb op het HBO ook een soort gelijke opdracht gehad met een heel fout datamodel. Dat leverde erg interessante query's op.
Het gaat er om hoe het nu juist niet moet, en daar leer je weer van ;P
Ik heb op het HBO ook een soort gelijke opdracht gehad met een heel fout datamodel. Dat leverde erg interessante query's op.
Het gaat er om hoe het nu juist niet moet, en daar leer je weer van ;P
Een fout datamodel kan inhouden dat het wiskundig niet klopt. Daar kun je op gaan querieen wat je wilt, daar zullen nooit correcte antwoorden uit kunnen komen. De database uit dit topic is daar een voorbeeld van, je hebt geen flauw idee wat de prijzen waren de afgelopen dagen/weken/maanden, dan kun je dus ook onmogelijk de omzet bepalen.
