select statment skal vises som kolonner

Du ville egentlig gerne have, hvis der var en streng baseret summation (concatenation) med en group by, hvis bare der var en list funktion, der samlede værdier efter group by.

SELECT kundenr, LIST(prod_id) FROM kundekoeb GROUP BY kundenr.

Men det kan man så bare ikke lige på den måde, så vidt jeg ved (og der er ikke ret meget, hehe). 

Hvis der er et endeligt antal af produkter som du vil have kan du jo prøve at lave en select for hver inde i hoved SQL

SELECT DISTINCT kundenr,
(SELECT prod_id FROM kundekoeb WHERE prod_id='mob') AS p1, (SELECT prod_id FROM kundekoeb WHERE prod_id='com') AS p2
FROM kundekoeb
WHERE kundenr = 1234

Nå ja, subqueries skal selvfølgelig linkes op til hovedforespørgslen, men det var selvfølgelig underforstået.

SELECT DISTINCT kundenr,
(SELECT pk1.prod_id FROM kundekoeb AS pk1 WHERE pk1.prod_id='mob' AND pk1.kundenr = kk.kundenr) AS p1, (SELECT pk2.prod_id FROM kundekoeb AS pk2 WHERE pk2.prod_id='com' AND pk2.kundenr = kk.kundenr) AS p2
FROM kundekoeb AS kk
WHERE kundenr = 1234

Ja det er en rimelig almindelig problemstilling, i virkeligheden burde den slags jo nok løses i applikationen :)

Anyway... jeg lavede en lille artikel om det her, hvordan det klares i T-Sql: http://janusknudsen.dk/post/T-SQL-Pivot-String-Concatenation-without-XML.aspx

janmanden-> din løsning fungerer ikke, hvad nu hvis der var mere eller mindre end 2?

Du er en stjern, en stjerne idé. Smid svar

Et svar mere :O)

Jeg skriver "hvis der et endeligt antal" og selvfølgelig så må ihtezaz vide hvad der af muligheder i hans egen tabel, så hvis han har 10 forkortelser så laver han bare 10 subqueries. Det er bestemt ikke dynamisk eller så elegant som det du linker til, men det virker og det fordeler data på kolonner. Hvis han endvidere navngiver alias med prod_id, så giver det jo unægteligt mere mening. Men pyt nu med.

janmanden-> Det er ikke sådan man programmerer noget, tingene skal laves ordentligt og robust og modsat gængs opfattelse så tager det ca. den samme tid :)

Janus->Det er ikke sådan man skal generalisere, forslag skal betragtes ud fra deres kontekst. Og her er et meget konkret tilfælde.

Koden er specifik og robust, men ikke dynamisk som nævnt et par gange nu. Det er ikke nogen god løsning at lave i SQL. Jeg ville foretrække at flytte noget af arbejdet til script i f.eks. php eller asp for at gøre det mere anvendeligt, men det var ikke lige spørgsmålet.

At klaske alle produkt kolonner sammen til et felt er måske den ene af løsninger og uden tvivl den smarteste, men det gør ikke ligefrem arbejdet nemmere og det skaber bestemt heller noget godt overblik. Det er da heldigt at han kigger på et produkt for hvis der var flere så blev det da noget værre rod at kigge på. Er det du mener med ordentligt og robust? :P

Hej janmanden, det virkede til det jeg skulle bruge det til, da det kun var et udtræk jeg skulle lave, så smid et svar.

Tak Janus, jeg til at læse din løsning også, jeg deler points i mellem jer.

janmanden-> Det er ikke at generalisere, det er at tænke sig om inden man koder noget. Det vælter rundt med dårlig kode, alle tror efterhånden de kan banke noget sammen, men det kræver omtanke at lave noget godt og robust. Derfor giver jeg sjældent løsninger ud, men vil langt hellere i dialog med problemstilleren og på den måde løse det bedst.

Min mantra: Fight bad code!

"Koden er specifik og robust, men ikke dynamisk som nævnt et par gange nu."

I softwaresammenhæng betyder robust ikke det du mener!

"Det er ikke nogen god løsning at lave i SQL. Jeg ville foretrække at flytte noget af arbejdet til script i f.eks. php eller asp for at gøre det mere anvendeligt, men det var ikke lige spørgsmålet. ""

Det har vi vidst aldrig været uenige om, det afhænger dog i høj grad af situationen, men generelt :)



Den kode vil jo aldrig komme til at virke lige end i det specielle tilfælde, du hardcoder jo prod_id, det ligner dog kode, men er det ikke :) Så kan man jo ligeså godt skrive det!

Og nej jeg mener ikke pointene skal deles, men det er op til dig!
janmanden har ikke bidraget med noget kodemæssigt, udover spørgsmål indpakket som svar *GG* - du vil finde ud af at selecten ikke fungerer.

haha,

Sjov side at se dig fra Janus, jeg har ikke set dig før tale ned til folk, og det synes jeg ikke godt om, men godt at du argumentere for dine valg ... men giver dig ret, fight bad code.

Om det virker pas.

Måske jeg skulle læse din artikel om emnet.

mvh

Læst og ville det ikke være hurtigere med sådan en Custom Aggregate ?

Bare for også at gøre det lidt flottere eller er functions i sql ligeså hurtige ?

Det er også meget sjældent det sker, men når janmanden slet ikke kan se hvad han selv har skrevet så ophører mine pædagogiske evner sku nok...

hmm, jeg tror nu nok til den slags simple ting at de performer nogenlunde ens. Det er nok mere når man kommer i gang med store stringmanipulationer og kompleks logik at CLR vil være en fordel.

Ja ... jeg tænker bare højt :-) Det kan altid give noget godt feedback. Nu snakkede vi jo også optimering og gøre det på den bedste måde, så synes det kunne være sjovt at høre om.

mvh

Jamen helt enig... det er faktisk også langt sjovere og mere givende at tale om tingene end bare smide resultater på bordet :)