Toon posts:

[SQL] tijd cummulatief weergeven *

Pagina: 1
Acties:

Verwijderd

Topicstarter
Ik heb volgende SQL-Query

SELECT Debiteur.Bedrijfsnaam, Registratie.Tijdsduur, Activiteit.Code,
Activiteit.Omschrijving FROM Debiteur, Registratie, Activiteit
WHERE registratie.debiteur_id = debiteur.id AND
registratie.activiteit_id = activiteit.id
ORDER BY debiteur.Bedrijfsnaam, Activiteit.Omschrijving

Deze geeft het volgende resultaat

Bedrijfsnaam Tijdsduur Code Omschrijving
-----------------------------------------------------------------------------------
Bedrijf1 2 060 Fin. Adm
Bedrijf1 1.5 060 Fin. Adm
Bedrijf1 4 070 Jaarrek
Bedrijf2 6 060 Fin. Adm
Bedrijf2 4 060 Fin. Adm


Ik wil graag een lijst waarbij de tijdsduur per code cummulatief wordt weergegeven.
Dus onderstaand resultaat.

Bedrijfsnaam Tijdsduur Code Omschrijving
----------------------------------------------------------------------------------
Bedrijf1 3.5 060 Fin. Adm
Bedrijf1 4 070 Jaarrek
Bedrijf2 10 060 Fin. Adm


Ben al aan het stoeien geweest met sub-Queries maar zonder resultaat.
Bovenstaande Query komt het meest in de buurt van het door mij gewenste resultaat.

Kan iemand mij tips geven.

  • jAnO!
  • Registratie: Januari 2002
  • Laatst online: 01-05 18:22

jAnO!

lalalavanillevla

Je moet gebruik maken van SUM en GROUP BY..
Dat moet je al flink op weg helpen denk ik.

When some people work at a place for ten years they get ten years of experience, other people work at a place for ten years and get one year of experience ten times.


Verwijderd

code:
1
2
3
4
5
6
7
8
9
10
11
SELECT
   min(Debiteur.Bedrijfsnaam), sum(Registratie.Tijdsduur), min(Activiteit.Code), 
   min(Activiteit.Omschrijving)
FROM 
    Debiteur, Registratie, Activiteit
WHERE 
    registratie.debiteur_id = debiteur.id AND registratie.activiteit_id = activiteit.id 
GROUP BY
    debiteur.id, activiteit.id
ORDER BY
    debiteur.Bedrijfsnaam, Activiteit.Omschrijving

:Y) zou een oplossing kunnen zijn... Hiermee moet je een beetje stoeien, dan kom je een aardig eind. Ik vraag me ook een beetje af waarom geen joins? FROM tabel1, tabel2, tabel3 staat zo clumsy vind ik :p

[ Voor 29% gewijzigd door Verwijderd op 23-06-2005 10:25 ]


  • jAnO!
  • Registratie: Januari 2002
  • Laatst online: 01-05 18:22

jAnO!

lalalavanillevla

Verwijderd schreef op donderdag 23 juni 2005 @ 10:22:
Ik vraag me ook een beetje af waarom geen joins? FROM tabel1, tabel2, tabel3 staat zo clumsy vind ik :p
Ik denk dat dat een kwestie van wennen is, ik heb het nog op de oude (dus de bovenstaande) manier (ORACLE) geleerd. Inmiddels probeer ik steeds vaker de nieuwe (1992 standaard) te gebruiken, maar stiekem blijf ik from tabel1, tabel2, tabel3 leesbaarder vinden.

When some people work at a place for ten years they get ten years of experience, other people work at a place for ten years and get one year of experience ten times.


  • mdcroon
  • Registratie: Januari 2005
  • Laatst online: 27-01-2025
Ook ik plak eigenlijk altijd nog de tabellen in de from clause achter elkaar. Maakt het uit (ik denk bv aan performance van de query) of je al dan niet werkt met joins (afgezien van het feit dat het de nieuwe standaard is)?

Verwijderd

Topicstarter
Bij bovenstaande Query krijg ik de melding dat debiteur.bedrijfsnaam geen onderdeel is van een aggregate function.

Iemand een idee?

Verwijderd

Verwijderd schreef op donderdag 23 juni 2005 @ 11:44:
Bij bovenstaande Query krijg ik de melding dat debiteur.bedrijfsnaam geen onderdeel is van een aggregate function.

Iemand een idee?
In de order-clause moet je de 2 omschrijvingen ook nog met een min(...) omsluiten, net als in de SELECT. Maar dit was puur uit t blote hoofdje zonder vergaande syntaxcheck :). Mag ik vragen waar deze query voor is?

[ Voor 5% gewijzigd door Verwijderd op 23-06-2005 11:49 ]


  • wizzkizz
  • Registratie: April 2003
  • Laatst online: 19-12-2025

wizzkizz

smile...tomorrow will be worse

Verwijderd schreef op donderdag 23 juni 2005 @ 11:44:
Bij bovenstaande Query krijg ik de melding dat debiteur.bedrijfsnaam geen onderdeel is van een aggregate function.

Iemand een idee?
in principe moet alles wat in je group-by clause staat ook in je select terugkomen, wat hier niet het geval is

[ Voor 5% gewijzigd door wizzkizz op 23-06-2005 11:51 ]

Make it idiot proof and someone will make a better idiot.
Real programmers don't document. If it was hard to write, it should be hard to understand.


  • Creepy
  • Registratie: Juni 2001
  • Laatst online: 18:51

Creepy

Tactical Espionage Splatterer

Eeh... hier zijn redelijk wat topics over voorbij gekomen? Alle dingen die niet in een aggregated function staan moet je in je group by opnemen. Daarij komt dat een MIN() op een string veld me niet echt nuttig lijkt.
Met een beetje SQL tutorial + logisch nadenken moet je hier wel uitkomen toch?

Overigens heb ik je topictitel ietsje zinniger gemaakt. "Probleem met SQL" zegt zo weinig ;) Zie ook *** Over topictitels in P&W - lezen voor topic openen!!! ***

[ Voor 22% gewijzigd door Creepy op 23-06-2005 11:53 ]

"I had a problem, I solved it with regular expressions. Now I have two problems". That's shows a lack of appreciation for regular expressions: "I know have _star_ problems" --Kevlin Henney


Verwijderd

Creepy schreef op donderdag 23 juni 2005 @ 11:50:
Daarbij komt dat een MIN() op een string veld me niet echt nuttig lijkt.
Met een beetje SQL tutorial + logisch nadenken moet je hier wel uitkomen toch?
Omdat de id's in de group by staan van de bedrijven maakt dat niet veel uit volgens mij of er een min() op een stringveld staat. Deze blijft toch gelijk? Tenminste, zo doen we dat hier ook wel eens :+ op een tabel met 10M+ records, performt prima :Y) .
Verder vind ik ook dat een SQL-tutorial uitkomst biedt...

  • jochemd
  • Registratie: November 2000
  • Laatst online: 29-12-2025
mdcroon schreef op donderdag 23 juni 2005 @ 11:13:
Ook ik plak eigenlijk altijd nog de tabellen in de from clause achter elkaar. Maakt het uit (ik denk bv aan performance van de query) of je al dan niet werkt met joins (afgezien van het feit dat het de nieuwe standaard is)?
Hoe zou je de volgende query zonder JOIN syntax schrijven?
code:
1
2
SELECT *
FROM a INNER JOIN b ON (a.a_id = b.a_id OR a.b_id = 6) NATURAL JOIN c


Ik vind het makkelijker om queries te schrijven met een JOIN syntax omdat het meestal voor een stuk logische scheiding zorgt. Relaties tussen tabellen, die meestal voortvloeien uit je schema, komen in je JOIN terecht, filtering van de resultaten in je WHERE. Dat komt overeen met hoe ik mijn queries schrijf: eerst de FROM, dan de WHERE, dan de GROUP BY, dan de rest.
Als je naar de letter van de SQL standaard kijkt is dat trouwens ook de volgorde waarin een database je query moet interpreteren. En als je naar de praktijk kijkt is dat ook meestal de volgorde waarin een query plan door de DBMS wordt opgebouwd. (Het verklaart ook waarom SELECT x AS y FROM z WHERE y =3 als het goed is niet door databases geaccepteerd wordt: de alias y is nog helemaal niet bekend op het moment dat de WHERE wordt uitgevoerd. (Sterker nog, je kan een veld y hebben en dan is het ambiguous of je het veld of de alias bedoeld.))

Uiteindelijk passen alle stukjes netjes in elkaar en zit er een zekere logica achter, maar als je gemiddelde query van het type SELECT * FROM table WHERE pk = 1 is heb je er niet zo veel mee te maken :)

  • mdcroon
  • Registratie: Januari 2005
  • Laatst online: 27-01-2025
jochemd schreef op donderdag 23 juni 2005 @ 14:22:
[...]

Hoe zou je de volgende query zonder JOIN syntax schrijven?
code:
1
2
SELECT *
FROM a INNER JOIN b ON (a.a_id = b.a_id OR a.b_id = 6) NATURAL JOIN c
Het bedrijf waar ik voor werk ontwikkelt software die op diverse DBMS'en moet kunnen draaien (Oracle, SQL Server, DB2 en Sybase). We proberen de SQL zoveel mogelijk aan de ANSI standaard te laten voldoen zodat in de software je niet per DBMS een SQL hoeft te schrijven. De NATURAL JOIN bijvoorbeeld wordt volgens mij niet door alle DBMS'en ondersteund en zal daarom door ons ook niet gebruikt worden.

Maar dit neemt niet weg dat ik in de toekomst hier vaker op ga letten. In ieder geval bedankt voor de toelichting.
Pagina: 1