[SQL]Query bestaande uit verschillende voorwaarden:

[pkouwer]

De query die ik moet uitvoeren bestaat in principe uit verschilende queries. Het gaat om gevoerde telefoongesprekken waarvan ik een rapport wil maken, met een onderscheidt van gesprekken naar regionaal,interregionaal,mobiel,buitenland en servicenummers. Globaal moet het er ongeveer zo uit gaan zien:

toestel | omschrijving | regio | interreg. | mobiel | buitenland | servicenrs
222 | pietje | 44 | 12 | 2 | 0 | 8

excuus voor de layout.

Het lijkt mij niet, maar kan ik dit in 1 query plaatsen of heb ik er 5 nodig per telefoontoestel ?

[P_de_B]

Even vooraf: welke database gebruik je, en kun je de layout van je tabel met wat voorbeeld data geven?

[lier]

pkouwer schreef op donderdag 21 april 2005 @ 07:59:
De query die ik moet uitvoeren bestaat in principe uit verschilende queries. Het gaat om gevoerde telefoongesprekken waarvan ik een rapport wil maken, met een onderscheidt van gesprekken naar regionaal,interregionaal,mobiel,buitenland en servicenummers. Globaal moet het er ongeveer zo uit gaan zien:

toestel | omschrijving | regio | interreg. | mobiel | buitenland | servicenrs
222 | pietje | 44 | 12 | 2 | 0 | 8

excuus voor de layout.

Het lijkt mij niet, maar kan ik dit in 1 query plaatsen of heb ik er 5 nodig per telefoontoestel ?

Inderdaad kan dit in een query ("groeperen op")

Even vooraf: welke database gebruik je, en kun je de layout van je tabel met wat voorbeeld data geven?

Database is niet "echt" belangrijk, gaat om een SQL vraag...

[P_de_B]

lier schreef op donderdag 21 april 2005 @ 08:15:
[...]


Inderdaad kan dit in een query ("groeperen op")


[...]
Database is niet "echt" belangrijk, gaat om een SQL vraag...

Het ligt eraan, ik heb het vermoeden dat de tabel er zo uit ziet:

Toestelid | GesprekTypeId | DuurGesprek

of iets vergelijkbaars. In dat geval zul je een Pivot op de data moeten uitvoeren. Hier zijn wel wat oplossingen voor, maar die zijn erg afhangkelijk van het gebruikte RDBMS. "SQL" is inderdaad een standaard maar tussen de verschillende RDBMSsen zit zoveel verschil dat je voor de wat ingewikkelder query wel moet weten welke je gebruikt. Denk bijvoorbeeld eens aan het wel of niet ondersteunen van subqueries.

[pkouwer]

database is nu nog Access, maar daarnaast moet het ook in MSSQL te doen zijn. Per klant bekijk ik welke database ik ga gebruiken.in de tabel registraties heb de volgende velden tot mijn beschikking:

id,datum,tijd,netlijn,toestel,wektijd,duur,telefoonnummer,oproeptype,simulatie,bedrag.

De belangrijkste velden hier zijn, toestel en telefoonnummer. Oproeptype moet 2 of 35 zijn. Dit laatste is het probleem niet.

[P_de_B]

En hoe bepaal je of het een internationaal, mobiel of regionaal nummer is? Op basis van het telefoonnummer?

[pkouwer]

op basis van telefoonnummer bepaal ik welk soort oproep het is. 06 = mobiel, 08 of 09 = servicenummer etc. Dit bepaal ik in een where-clause. In de rest van mijn applicatie werkt dit perfect !

[lier]

En heb je al gekeken naar sommeren in combinatie met groeperen op (SUM, GROUP BY) ?

[pkouwer]

uiteraard, maar ik heb voor de mobiele nummers een andere WHERE-clause dan voor buitenland. Hoe kan ik dit afvangen ?

[P_de_B]

lier schreef op donderdag 21 april 2005 @ 08:39:
En heb je al gekeken naar sommeren in combinatie met groeperen op (SUM, GROUP BY) ?

Dat werkt in dit geval toch niet? De gegevens moeten gepivot worden

---

Ik zou toch ter overweging willen geven om het type telefoongesprek apart op te nemen. Je moet nu met stringfuncties het telefoonnummer manipuleren om het type te bepalen, dit zal de snelheid niet ten goede komen.

Voor de oplossing van je probleem kun je iets als het volgende doen

code:

SELECT Toestel, (SELECT COUNT(*) FROM Tabel WHERE Toestel = T.Toestel and LEFT(telefoonnr, 2) = '06') as Mobiel,  (SELECT COUNT(*) FROM Tabel WHERE Toestel = T.Toestel and LEFT(telefoonnr, 2) = '09') as Service
FROM Tabel T

Je moet dus voor elke kolom in je eindrapport een zgn correlated subquery opnemen. Ik denk dat je wel ziet hoe het werkt. Als je nog de tabel kunt wijzigen en een gesprektype kunt opnemen zou je hier nog kunnen kijken: klik

[ Voor 2% gewijzigd door P_de_B op 21-04-2005 08:59 . Reden: url gefixt ]

[pkouwer]

helaas kan ik de tabel niet meer wijzigen, daarvoor is het programma reeds te ver doorontwikkeld en geinstalleerd bij klanten.

[P_de_B]

pkouwer schreef op donderdag 21 april 2005 @ 09:05:
helaas kan ik de tabel niet meer wijzigen, daarvoor is het programma reeds te ver doorontwikkeld en geinstalleerd bij klanten.

Dan zul je dus iets met de subquery oplossing moeten doen.

[curry684]

pkouwer schreef op donderdag 21 april 2005 @ 09:05:
helaas kan ik de tabel niet meer wijzigen, daarvoor is het programma reeds te ver doorontwikkeld en geinstalleerd bij klanten.

En sinds wanneer kun je dan geen ALTER TABLE gevolgd door een paar automated conversiescripts meer erop loslaten?

[Robbemans]

En sinds wanneer kun je dan geen ALTER TABLE gevolgd door een paar automated conversiescripts meer erop loslaten?

Hoogstwaarschijnlijk is het gewoon niet haalbaar om de tabel (nog) te wijzigen. Dit kan een plethora aan oorzaken hebben. Voor een moderator een beetje een vreemde opmerking, imho...

Ontopic:

Als je gebruik maakt van MS SQL Server kun je het zo te zien met een boolean aggregate oplossen. Dit is een manier om te sommeren per record, zonder dat je tig subqueries hoeft uit te voeren om je data boven tafel te krijgen. Zie hier voor meer uitleg hierover: http://www.stephenforte.n...18-4ac0-a405-15d6d813eeb8

[ Voor 37% gewijzigd door Robbemans op 21-04-2005 10:47 ]

[P_de_B]

Robbemans schreef op donderdag 21 april 2005 @ 10:45:
[...]


Hoogstwaarschijnlijk is het gewoon niet haalbaar om de tabel (nog) te wijzigen. Dit kan een plethora aan oorzaken hebben. Voor een moderator een beetje een vreemde opmerking, imho...

Ontopic:

Als je gebruik maakt van MS SQL Server kun je het zo te zien met een boolean aggregate oplossen. Dit is een manier om te sommeren per record, zonder dat je tig subqueries hoeft uit te voeren om je data boven tafel te krijgen. Zie hier voor meer uitleg hierover: http://www.stephenforte.n...18-4ac0-a405-15d6d813eeb8

Ik ben het ermee eens dat de opmerking niet terecht is, er kunnen idd veel verschillende oorzaken zijn. Wat zijn Admin Dokstersteam titel hiermee nodig heeft snap ik weer niet.

De link die je gegeven hebt, had ik al een aantal posts hierboven staan

[curry684]

Robbemans schreef op donderdag 21 april 2005 @ 10:45:
[...]

Hoogstwaarschijnlijk is het gewoon niet haalbaar om de tabel (nog) te wijzigen. Dit kan een plethora aan oorzaken hebben.

En ik vraag dus waarom dat niet haalbaar is Hij is functionaliteit aan het wijzigen voor een nieuwe release, dus code moet ie sowieso uitrollen naar alle klanten. Waarom zou daar geen database-updatescript bij uitgevoerd kunnen worden? Op deze manier zit je tot in lengte van dagen vast aan je originele design van versie 1.0, dat schiet ook niet op.

Voor een moderator een beetje een vreemde opmerking, imho...

Wat heeft het feit dat ik admin ben, en dan nog niet eens van een forumonderdeel dat aan Programming & Webscripting gerelateerd is, in godesnaam te maken met of ik wel of niet technische vragen mag plaatsen hier?

[Robbemans]

curry684 schreef op donderdag 21 april 2005 @ 10:55:
[...]

En ik vraag dus waarom dat niet haalbaar is Hij is functionaliteit aan het wijzigen voor een nieuwe release, dus code moet ie sowieso uitrollen naar alle klanten. Waarom zou daar geen database-updatescript bij uitgevoerd kunnen worden? Op deze manier zit je tot in lengte van dagen vast aan je originele design van versie 1.0, dat schiet ook niet op.

[...]

Wat heeft het feit dat ik admin ben, en dan nog niet eens van een forumonderdeel dat aan Programming & Webscripting gerelateerd is, in godesnaam te maken met of ik wel of niet technische vragen mag plaatsen hier?

Waarom het niet haalbaar is geeft de topicstarter een uur voor je post al aan. Het programma is in een al te ver gevorderd stadium om nu nog tabellen te gaan wijzigen. Het heeft in zoverre met je ADMIN status te maken dat er regelmatig door de admins op wordt gewezen alleen te posten indien dit zin heeft. Ik bedoel hier absoluut geen flame mee, maar ik vond je opmerking enigszins off topic, gezien de onmogelijkheid die al werd aangegeven.

[curry684]

Robbemans schreef op donderdag 21 april 2005 @ 11:20:
[...]

Waarom het niet haalbaar is geeft de topicstarter een uur voor je post al aan. Het programma is in een al te ver gevorderd stadium om nu nog tabellen te gaan wijzigen.

Dat is gewoon onzin. Het is reeds geinstalleerd bij klanten, en dus moet wat hij nu aan het programmeren is los uitgerold worden. Dan kan er zoals ik al 3 keer zeg ook een DB-update script bij.

Het heeft in zoverre met je ADMIN status te maken dat er regelmatig door de admins op wordt gewezen alleen te posten indien dit zin heeft.

Ik vind het feit dat je een database probleemloos bij iedere (tussen)release kunt updaten zelfs bij een gereleased produkt nogal relevant voor deze discussie. En als je het daar niet mee eens bent maak je maar een topic report zodat de P&W-crew zich erover kan buigen ipv publiek mijn functioneren in twijfel te trekken.

ik vond je opmerking enigszins off topic, gezien de onmogelijkheid die al werd aangegeven.

Nee hij zegt dat het onmogelijk is en ik trek dat in twijfel. Als iemand zegt dat het in C++ onmogelijk is om pointers te gebruiken trek ik dat ook in twijfel, en vraag ik hoe die persoon aan die imho foutieve mening komt.

[Robbemans]

curry684 schreef op donderdag 21 april 2005 @ 11:33:
[...]

Dat is gewoon onzin. Het is reeds geinstalleerd bij klanten, en dus moet wat hij nu aan het programmeren is los uitgerold worden. Dan kan er zoals ik al 3 keer zeg ook een DB-update script bij.

[...]

Ik vind het feit dat je een database probleemloos bij iedere (tussen)release kunt updaten zelfs bij een gereleased produkt nogal relevant voor deze discussie. En als je het daar niet mee eens bent maak je maar een topic report zodat de P&W-crew zich erover kan buigen ipv publiek mijn functioneren in twijfel te trekken.

[...]

Nee hij zegt dat het onmogelijk is en ik trek dat in twijfel. Als iemand zegt dat het in C++ onmogelijk is om pointers te gebruiken trek ik dat ook in twijfel, en vraag ik hoe die persoon aan die imho foutieve mening komt.

Punt 1: Helemaal mee eens wat betreft een eventueel script dat meegestuurd kan worden.

Punt 2: Ik geef alleen aan dat de topicstater (om welke reden dan ook) geen wijzigingen meer aan de tabel kan doen. Het zou best kunnen dat een tussentijdse wijziging op het datamodel mogelijk is...
Daarnaast trek ik je functioneren totaal niet in twijfel. Niets dan lof over je posts. Als je goed leest zie je dat ik niet de enige ben de de mening van de 'offtopic mededeling' toegedaan is. Het viel gewoon op en ik maak er een melding van. Big deal...
Om nou niet te verzanden in een welles nietes spelletje denk ik dat we het hier maar bij moeten houden wat betreft het wel/niet on-topic zijn van je mededeling, omdat dit (zoals je aangeeft) en plein publiek niet prettig voor je kan zijn. Nogmaals: no flame intended!

Punt 3: Mooie analogie. je kunt het idd in twijfel trekken. Wellicht kan de topicstarter aangeven waarom de tabel niet meer gewijzigd kan worden.

[ Voor 3% gewijzigd door Robbemans op 21-04-2005 11:40 ]

[Rac-On]

Curry, uit ervaring weet ik dat het wijzigen van een database layout in een groot & complex systeem (bijvoorbeeld het billen van telefoniegesprekken) niet zo makkelijk is. Los van het feit hoeveel tijd het kost je huidige applicatie aan te passen, zijn er altijd nog een hele schare andere programma's die met dezelfde database communiceren. Aangezien wij (en dus jij ook) niet weten welke andere programma's + interfaces er nog met deze database moeten werken, is het nogal kort door de bocht om te stellen "dat je een database probleemloos bij iedere (tussen)release kunt updaten"
Ik ben het met je eens dat vaak na een tijdje gebruik er achter komt dat een bepaald data model niet handig is, maar het aanpassen van je database + bijbehorende applicaties kost vaak/soms dusdanig veel tijd, dat de kosten niet meer opwegen tegen de baten en je zult moeten werken met wat er is.

[curry684]

rac-on schreef op donderdag 21 april 2005 @ 11:43:
Curry, uit ervaring weet ik dat het wijzigen van een database layout in een groot & complex systeem (bijvoorbeeld het billen van telefoniegesprekken) niet zo makkelijk is. Los van het feit hoeveel tijd het kost je huidige applicatie aan te passen, zijn er altijd nog een hele schare andere programma's die met dezelfde database communiceren. Aangezien wij (en dus jij ook) niet weten welke andere programma's + interfaces er nog met deze database moeten werken, is het nogal kort door de bocht om te stellen "dat je een database probleemloos bij iedere (tussen)release kunt updaten"
Ik ben het met je eens dat vaak na een tijdje gebruik er achter komt dat een bepaald data model niet handig is, maar het aanpassen van je database + bijbehorende applicaties kost vaak/soms dusdanig veel tijd, dat de kosten niet meer opwegen tegen de baten en je zult moeten werken met wat er is.

Ik ben het er helemaal mee eens dat het niet altijd mogelijk/wenselijk is om de DB te updaten bij een intermediate release, ik neem alleen geen vrede met "het kan niet" als excuus om met een fout datamodel rond te blijven lopen, wellicht schat TS de wijziging moeilijker in dan hij is en dan kunnen we hem daarmee behulpzaam zijn

Zeker in dit geval overigens, simpelweg het toevoegen van een optioneel veldje aan een tabel, zou het echt geen probleem moeten zijn.

[pkouwer]

de wijziging van de database is nl. niet voor alle klanten van toepassin. Slechts een paar ervan hebben dit nodig. Geloof me: aanpassen is geen optie!

[Robbemans]

Je kunt dit in eerste instantie met subqueries oplossen. Dat moet niet zo lastig zijn.