[SQL] Oplopend totaal

[Verwijderd]

Ik wil een query schrijven waarin en oplopend totaal staat. Het werkt als volgt:

Ik heb etappes, en aan elke etappe doen meerdere fietsers mee. Ze krijgen punten per etappe en deze punten moet ik cumulatief per etappe in EEN query kunnen zien. Kan dat?

Voorbeeld:

code:

Etappe fietser punten
1          1         2
2          1         3
3          1         4

Resultaat:
1          1         2
2          1         5
3          1         9

Ik maak gebruik van postgres. Ik weet hoe ik het in mijn code moet oplossen, maar ik wil het doen in sql of plsql.

[whoami]

Ik SQL Server heb je een WITH ROLLUP en WITH CUBE clausule waarmee dat mogelijk is.
klik.

Ik weet echter niet of iets dergelijks ook in Postgress mogelijk is.

[Verwijderd]

Dat is niet helemaal wat ik bedoel. Deze geven een soort van grouped sum. Ik moet een cumulatieve sum hebben.

[Verwijderd]

Ik gebruik zelf MySQL voor mijn database, waarschijnlijk lijkt het er sterk op. Als ik het goed begrijp will je een lijstje met fietsers en de punten van die fietser. Dan moet je de punten bij elkaar optellen met SUM en vervolgens alles groeperen per fietser. In MySQL wordt dat dan het volgende:

code:

select fietser,sum(punten) from tabel group by fietser

Maar dit is dus MySQL, ik heb daar alleen verstand van maar hoop je zo toch te helpen. Ik ga er dus vanuit dat 'tabel' je tabelnaam is waar de gegevens in staan en dat 'fietser' en 'punten' je veldnamen zijn in de tabel.

Maar volgensmij begrijp ik niet goed wat je wilt want ik zie dat anderen er heel anders over denken

edit:
code verandert

[ Voor 7% gewijzigd door Verwijderd op 04-05-2004 09:28 ]

[Verwijderd]

Cumulatieve totalen zijn niet mogelijk in SQL omdat je geaggregeerde data samen met single row data af wilt drukken.

[cameodski]

Deze query doet denk ik ongeveer wat je zoekt:

code:

select t1.etappe, t1.fietser, SUM(t2.punten) as punten
from table as t1
inner join table as t2 on (t2.fietser = t1.fietser and t2.etappe <= t1.etappe)
group by t1.etappe, t1.fietser

Erg snel zijn dit soort queries trouwens niet.

edit:
oeps, group by vergeten

[ Voor 18% gewijzigd door cameodski op 04-05-2004 09:46 ]

[curry684]

Verwijderd schreef op 04 mei 2004 @ 09:29:
Cumulatieve totalen zijn niet mogelijk in SQL omdat je geaggregeerde data samen met single row data af wilt drukken.

Je omschrijft het wat moeilijk maar het klopt wel

SQL is een taal om set-based data te manipuleren. De topicstarter wil set-based data vormen gebaseerd op basis van de sorted positie van de data in het resultaat, wat row-based data impliceert. Om deze reden heeft SQL er geen faciliteiten voor: het is geen set-based operatie. Je zult het dus in de omliggende code moeten doen, of met een creatieve stored procedure/trigger waarin je een column automatisch calculeert op basis van de SUM van rows met een lager ID als zichzelf.

[Verwijderd]

Ik heb een voorbeeld gevonden met een CROSS JOIN op:

http://www.sqlteam.com/item.asp?ItemID=3856

Ik ben nu aan het proberen of het lukt.

[cameodski]

curry684 schreef op 04 mei 2004 @ 09:33:
Je omschrijft het wat moeilijk maar het klopt wel

SQL is een taal om set-based data te manipuleren. De topicstarter wil set-based data vormen gebaseerd op basis van de sorted positie van de data in het resultaat, wat row-based data impliceert. Om deze reden heeft SQL er geen faciliteiten voor: het is geen set-based operatie. Je zult het dus in de omliggende code moeten doen, of met een creatieve stored procedure/trigger waarin je een column automatisch calculeert op basis van de SUM van rows met een lager ID als zichzelf.

SQL is inderdaad niet bedoeld voor dit soort zaken, maar het kan wel. Alleen moet als je ook nog aan de performance wilt denken, wat anders verzinnen.

Verwijderd schreef op 04 mei 2004 @ 09:35:
Ik heb een voorbeeld gevonden met een CROSS JOIN op:

http://www.sqlteam.com/item.asp?ItemID=3856

Ik ben nu aan het proberen of het lukt.

Had je mijn vorige reactie al gelezen. Die bedoelt hetzelfde.

[ Voor 19% gewijzigd door cameodski op 04-05-2004 09:45 ]

[curry684]

CROSS JOIN

Je weet hopelijk dat op die manier 200 renners met 100 rondjes je een table scan van 20000*20000 = 400 miljoen rows op gaat leveren iedere keer dat je de query uitvoert?

[Verwijderd]

OK ik zie het al, gewoon coden!

[cameodski]

curry684 schreef op 04 mei 2004 @ 09:46:
CROSS JOIN

Je weet hopelijk dat op die manier 200 renners met 100 rondjes je een table scan van 20000*20000 = 400 miljoen rows op gaat leveren iedere keer dat je de query uitvoert?

Als er slechts een beperkt aantal renners en rondjes relevant is, zou de optimizer intelligent genoeg moeten zijn om het snel uit te voeren.

Maar met dit soort queries zet je wel de deur open naar een ernstig performance probleem.

[Verwijderd]

Dan lijkt het me geen goed idee, aangezien je alle wielerklassiekers erin moet kunnen zetten incl de tour uiteraard.

[cameodski]

Verwijderd schreef op 04 mei 2004 @ 10:20:
Dan lijkt het me geen goed idee, aangezien je alle wielerklassiekers erin moet kunnen zetten incl de tour uiteraard.

Het gaat er niet in de eerste plaats om wat je erin zet, maar veel meer wat je er uithaalt.
Als je bijvoorbeeld van tien renners wilt weten hoeveel punten ze hebben na de tiende etappe dan zal dat niet zo'n probleem zijn.
Maar als je van 200 renners na 20 etappes wilt weten welke posities ze in het klassement hebben dan wordt het al een iets ander verhaal.
Maar als aan het eind van de tour alle renners met alle etappes wilt hebben, dan heb je onderhand toch al wel een probleem.

[Verwijderd]

Dat is precies wat ik wil. Ik prog het nu anders: ik sla alle scores hard op na elke etappe.

[curry684]

Verwijderd schreef op 04 mei 2004 @ 09:48:
OK ik zie het al, gewoon coden!

Zoek eens op de term 'carthesisch produkt'

[Verwijderd]

Ik zo'n query een maand geleden ongeveer moeten schrijven.

stappen:
1. creer een view (create view) waar je het resultaat bekomt zoals in query1.


2. creer een query op basis van deze view waar je het volgend gaat op toepassen

SQL:

select ettape,fiester
    ,(select sum(punten) from view1 
                          where ettape <= O.ettape)
    
from view1 O

dit is een mogelijkheid, maar je zit wel met een super trage query

bron van deze techniek:

http://www.databasejourna...mssql/article.php/3112381

zoeken op: running totals sql

[curry684]

s-man2: die mogelijkheid had ik reeds gemeld, maar is niet geschikt voor duizenden etappes en duizenden renners

[beetle71]

Geen oplossing voor het probleem van de TS , maar wel een heel interessant stukje over cross tabulation in MySQL. (en evt.oplossing) http://dev.mysql.com/tech...wizard/print_version.html

[Verwijderd]

curry684 schreef op 04 mei 2004 @ 12:22:
s-man2: die mogelijkheid had ik reeds gemeld, maar is niet geschikt voor duizenden etappes en duizenden renners

Ik heb zelf dergelijke queries gerund op een resultset van 60 .000 records. Op een p3 met 512 ram duurt het in acces ongeveer 15 min. om deze query te laten runnen. Het is dus wel best mogelijk

[cameodski]

Verwijderd schreef op 04 mei 2004 @ 15:09:
[...]

Ik heb zelf dergelijke queries gerund op een resultset van 60 .000 records. Op een p3 met 512 ram duurt het in acces ongeveer 15 min. om deze query te laten runnen. Het is dus wel best mogelijk

Ja, en als het een hele dag duurt is het nog steeds mogelijk
Maar in een productie omgeving is dat meestal volstrekt onacceptabel en als we het over een multi-user omgeving hebben en één keer in de tien minuten wordt zo'n query uitgevoerd dan heb je toch echt een ernstig probleem.

[curry684]

Verwijderd schreef op 04 mei 2004 @ 15:09:
[...]

Ik heb zelf dergelijke queries gerund op een resultset van 60 .000 records. Op een p3 met 512 ram duurt het in acces ongeveer 15 min. om deze query te laten runnen. Het is dus wel best mogelijk

15 minuten op elke query die niet eenmalig is is overal onacceptabel

[klinz]

Verwijderd schreef op 04 mei 2004 @ 09:29:
Cumulatieve totalen zijn niet mogelijk in SQL omdat je geaggregeerde data samen met single row data af wilt drukken.

Hoe fout ook, met MySQL kan dat wel.

[Verwijderd]

klinz schreef op 04 mei 2004 @ 22:43:
[...]
Hoe fout ook, met MySQL kan dat wel.

Dat wil ik zien, zou je een voorbeeld kunnen posten ?

[klinz]

Verwijderd schreef op 05 mei 2004 @ 13:23:
Dat wil ik zien, zou je een voorbeeld kunnen posten ?

tabel(id, waarde)

code:

select id, max(waarde)
from tabel
group by waarde

[cameodski]

klinz schreef op 07 mei 2004 @ 13:20:
[...]

tabel(id, waarde)

code:

select id, max(waarde)
from tabel
group by waarde

Volgens mij heb je niet begrepen wat de bedoeling is. En je query klopt ook niet.

[Verwijderd]

klinz schreef op 07 mei 2004 @ 13:20:
[...]

tabel(id, waarde)

code:

select id, max(waarde)
from tabel
group by waarde

Treurig, diep treurig

[klinz]

Lezen jongens. Het was een voorbeeld van het op incorrecte wijze mixen van row data en aggregate data. Niet de oplossing voor het probleem van de TS. In MySQL mag dat namelijk. Misschien moet ik nog even melden dat het gedrag van MySQL wat dat betreft niet klopt?

[cameodski]

klinz schreef op 07 mei 2004 @ 15:07:
Lezen jongens. Het was een voorbeeld van het op incorrecte wijze mixen van row data en aggregate data. Niet de oplossing voor het probleem van de TS. In MySQL mag dat namelijk. Misschien moet ik nog even melden dat het gedrag van MySQL wat dat betreft niet klopt?

Jouw query toch echt niet aan hetgeen waarvan vteuniss zei dat het niet mogelijk is.
Als je de query in mijn eerste post uitprobeert, denk ik dat je zult ontdekken dat het in MySQL wel mogelijk is. Maargoed, dat was dus allang genoemd en beetje onnodig om nog een keertje te posten.

En dat MySQL dingen doet die echt nergens op slaan, is weer een ander verhaal.

[ Voor 7% gewijzigd door cameodski op 07-05-2004 15:20 ]

[klinz]

[..] denk ik dat je zult ontdekken dat het in MySQL wel mogelijk is.

Dat zeg ik.