/ Forside / Teknologi / Udvikling / SQL / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
SQL
#NavnPoint
pmbruun 1704
niller 962
fehaar 730
Interkril.. 701
ellebye 510
pawel 510
rpje 405
pete 350
gibson 320
10  smorch 260
Problemer med SQL Søgesætning
Fra : Henrik


Dato : 02-01-08 21:19

Hejsa

Jeg mangler lidt hjælp til en søge sætning

Udsnit af databasen

CUSTID PRODUCT ITEM
1 265 56
1 22 2000
1 700 20
2 700 25
2 9 34
3 700 2200

Det jeg gerne vil have ud er:

CUSTID PRODUCT ITEM
1 22 2000
2 9 34
3 700 2200

Er det en der kan hjælpe med en søge sætning?




 
 
Philip Nunnegaard (02-01-2008)
Kommentar
Fra : Philip Nunnegaard


Dato : 02-01-08 21:30

"Henrik" <ha@spam.dk> skrev i meddelelsen
news:477bf1cf$0$15881$edfadb0f@dtext01.news.tele.dk...

> Er det en der kan hjælpe med en søge sætning?

Det kommer an på, efter hvilke kriterier du har valgt lige de 3 ud.
Hvis vi antager, at du vil have én forekomst af hver CUSTID-værdi, og det
skal være den post, der har den højeste ITEM-værdi, må det blive:

select CUSTID,PRODUCT,ITEM from navn_paa_din_tabel group by CUSTID order by
ITEM desc


Henrik (02-01-2008)
Kommentar
Fra : Henrik


Dato : 02-01-08 22:25

Det virker ikke helt.

Jeg skal bruge en forkomst fra CUSTID, den skal så finde den ITEM med den
højst værdi, Samt det PRODUCT der passer til den højst ITEM.

Jeg har prøvet med denne sætning:

select CUSTID, PRODUCT, MAX(ITEM) from subscriptions GROUP BY CUSTID

Men den trækker ikke det rigtig PRODUCT med over





"Philip Nunnegaard" <philip@fjerndettehitsurf.dk> skrev i en meddelelse
news:477bf440$0$15899$edfadb0f@dtext01.news.tele.dk...
> "Henrik" <ha@spam.dk> skrev i meddelelsen
> news:477bf1cf$0$15881$edfadb0f@dtext01.news.tele.dk...
>
>> Er det en der kan hjælpe med en søge sætning?
>
> Det kommer an på, efter hvilke kriterier du har valgt lige de 3 ud.
> Hvis vi antager, at du vil have én forekomst af hver CUSTID-værdi, og det
> skal være den post, der har den højeste ITEM-værdi, må det blive:
>
> select CUSTID,PRODUCT,ITEM from navn_paa_din_tabel group by CUSTID order
> by ITEM desc



Philip Nunnegaard (02-01-2008)
Kommentar
Fra : Philip Nunnegaard


Dato : 02-01-08 22:54

"Henrik" <ha@spam.dk> skrev i meddelelsen
news:477c0156$0$15876$edfadb0f@dtext01.news.tele.dk...

> Det virker ikke helt.

OK, men den burde nu trække én forekomst fra CUSTID ud. Så dit problem med
min SQL-sætning er nok mere, at den ikke hiver den *rigtige* forekomst ud?

> select CUSTID, PRODUCT, MAX(ITEM) from subscriptions GROUP BY CUSTID

Måske:
select CUSTID, PRODUCT, MAX(ITEM) as maxitem from subscriptions GROUP BY
CUSTID

> Men den trækker ikke det rigtig PRODUCT med over

Mystisk! Har lige afprøvet din SQL-sætning på en af mine egne tabeller
(selvfølgelig med andre kolonner), og det virkede fint (MySQL).

Måske der kunne komme lidt flere kloge hoveder på banen, hvis de vidste,
hvilken database det er, du roder med.
Der er ind imellem forskel i syntaksen alt efter om det er MySQL eller MS
SQL. Dog mener jeg også, at max() skulle virke i MS-databaser.


Peter Brodersen (03-01-2008)
Kommentar
Fra : Peter Brodersen


Dato : 03-01-08 08:47

On Wed, 2 Jan 2008 22:54:18 +0100, "Philip Nunnegaard"
<philip@fjerndettehitsurf.dk> wrote:

>OK, men den burde nu trække én forekomst fra CUSTID ud. Så dit problem med
>min SQL-sætning er nok mere, at den ikke hiver den *rigtige* forekomst ud?
>
>> select CUSTID, PRODUCT, MAX(ITEM) from subscriptions GROUP BY CUSTID

Som sådan er det ikke gyldig SQL at henvise direkte til kolonner, man
ikke GROUP'er på, uden at de er i en aggrerings-funktion.

Hvis man alligevel gør det, så vælger MySQL så bare en vilkårlig værdi
af de værdier, der bliver aggregeret, men der er ingen garanter for
hvilken af dem, det er.

--
- Peter Brodersen
Kendt fra Internet

Philip Nunnegaard (03-01-2008)
Kommentar
Fra : Philip Nunnegaard


Dato : 03-01-08 13:27

"Peter Brodersen" <usenet2007@ter.dk> skrev i meddelelsen
news:477c9368$0$90270$14726298@news.sunsite.dk...

> Som sådan er det ikke gyldig SQL at henvise direkte til kolonner, man
> ikke GROUP'er på, uden at de er i en aggrerings-funktion.
>
> Hvis man alligevel gør det, så vælger MySQL så bare en vilkårlig værdi
> af de værdier, der bliver aggregeret, men der er ingen garanter for
> hvilken af dem, det er.

OK! Så man skal altså gøre, som Jan Bachman foreslår: Lave en innerjoin på
samme tabel.
Det giver mening, selv om jeg ville mene, at det trækker lidt hårdere på
serveren, end hvis den anden metode havde virket efter hensigten.


Peter Brodersen (05-01-2008)
Kommentar
Fra : Peter Brodersen


Dato : 05-01-08 04:42

On Thu, 3 Jan 2008 13:26:44 +0100, "Philip Nunnegaard"
<philip@fjerndettehitsurf.dk> wrote:

>OK! Så man skal altså gøre, som Jan Bachman foreslår: Lave en innerjoin på
>samme tabel.
>Det giver mening, selv om jeg ville mene, at det trækker lidt hårdere på
>serveren, end hvis den anden metode havde virket efter hensigten.

Den anden metode ville kræve lidt for meget magi. Tænk på, at man kan
lave flere aggregerede opslag, fx:

select CUSTID, PRODUCT, MAX(ITEM), MIN(ITEM)
from subscriptions
GROUP BY CUSTID

Hvilket PRODUCT skulle så tages med over? Det som knytter sig til
MAX(ITEM) eller det som knytter sig til MIN(ITEM)?

Vi kunne i princippet også bruge AVG() eller STD() eller SUM() eller
COUNT() som andre aggregerings-funktioner. Det ville bare give
mulighed for endnu mere rod.


Derudover, og måske mere vigtigt er der et andet helt basalt
design-problem med den metode: at ét af felterne i udtrækket skulle
blive påvirket af udtrækket af et andet felt. Altså, at ved SELECT x,
(udtryk), z FROM ... så ville z kunne variere, alt efter hvad x eller
udtrykket rummede.

Et felts værdi skal ikke blive påvirket af andre værdier i udtrækket
(her undtaget brugen af variable o.lign). Det hører til et helt andet
sted i SQL-forespørgslen.


Det ekstra opslag er i øvrigt næppe noget performance-problem -
forudsat at der er et index på (CUSTID, ITEM)

--
- Peter Brodersen
Kendt fra Internet

Jan Bachman (03-01-2008)
Kommentar
Fra : Jan Bachman


Dato : 03-01-08 09:05

On Wed, 2 Jan 2008 22:25:02 +0100, "Henrik" <ha@spam.dk> wrote:

>Det virker ikke helt.
>
>Jeg skal bruge en forkomst fra CUSTID, den skal så finde den ITEM med den
>højst værdi, Samt det PRODUCT der passer til den højst ITEM.
>
>Jeg har prøvet med denne sætning:
>
>select CUSTID, PRODUCT, MAX(ITEM) from subscriptions GROUP BY CUSTID
>
>Men den trækker ikke det rigtig PRODUCT med over

select subscriptions.*
from subscriptions
inner join (
select custid, max(item) maxitem
from subscriptions
group by custid
) nest
on subscriptions.custid = nest.custid
and subscriptions.item = nest.maxitem

/Jan

Henrik (03-01-2008)
Kommentar
Fra : Henrik


Dato : 03-01-08 18:41

Hvad betyder "nest"? og hvad gør det godt for?

Henrik

"Jan Bachman" <jamen@davs.du> skrev i en meddelelse
news:vg5pn3pojd5eepav0bggj9mc8afbfd6lt5@4ax.com...
> On Wed, 2 Jan 2008 22:25:02 +0100, "Henrik" <ha@spam.dk> wrote:
>
>>Det virker ikke helt.
>>
>>Jeg skal bruge en forkomst fra CUSTID, den skal så finde den ITEM med den
>>højst værdi, Samt det PRODUCT der passer til den højst ITEM.
>>
>>Jeg har prøvet med denne sætning:
>>
>>select CUSTID, PRODUCT, MAX(ITEM) from subscriptions GROUP BY CUSTID
>>
>>Men den trækker ikke det rigtig PRODUCT med over
>
> select subscriptions.*
> from subscriptions
> inner join (
> select custid, max(item) maxitem
> from subscriptions
> group by custid
> ) nest
> on subscriptions.custid = nest.custid
> and subscriptions.item = nest.maxitem
>
> /Jan



Jan Bachman (03-01-2008)
Kommentar
Fra : Jan Bachman


Dato : 03-01-08 19:17

On Thu, 3 Jan 2008 18:41:10 +0100, "Henrik" <ha@spam.dk> wrote:

>Hvad betyder "nest"? og hvad gør det godt for?

Kært barn mange navne:
- Nested queries.
- Sub-queries.
- Underforespørgsler.
- Indlejrede forespørgsler

Søg gerne lidt på google, hvis det er nyt for dig.

Konceptet drejer sig om at have en SQL-sætning (select), som man
indkapsler (eller nester, som jeg ynder at kalde det), og refererer
til i en ny ydre SQL-sætning. Ordet "nest" i mit eksempel er bare det
navn, som jeg tildeler det inderste udtryk, og som jeg bruger til at
referere til det, som var det en tabel.

/Jan

Henrik (03-01-2008)
Kommentar
Fra : Henrik


Dato : 03-01-08 20:05

Har søgt lidt på nettet inden jeg skrev her.
men jeg forstår det stadig ikke, bruger du "nest" som et fiktiv navn?

Prolemet er at jeg ikke kan få din søge sætning til at virke
Det er nogle data som jeg skal hente ud af en gammel mysql database, og til
det formål har jeg fundet et program der hedder urSQL, ved ikke om det er
programmet der ikke kan finde ud af det, eller om jeg ud og søge efter noget
andet.


"Jan Bachman" <jamen@davs.du> skrev i en meddelelse
news:0f8qn3tvlsokl91rgsj8p6r611jqiksut7@4ax.com...
> On Thu, 3 Jan 2008 18:41:10 +0100, "Henrik" <ha@spam.dk> wrote:
>
>>Hvad betyder "nest"? og hvad gør det godt for?
>
> Kært barn mange navne:
> - Nested queries.
> - Sub-queries.
> - Underforespørgsler.
> - Indlejrede forespørgsler
>
> Søg gerne lidt på google, hvis det er nyt for dig.
>
> Konceptet drejer sig om at have en SQL-sætning (select), som man
> indkapsler (eller nester, som jeg ynder at kalde det), og refererer
> til i en ny ydre SQL-sætning. Ordet "nest" i mit eksempel er bare det
> navn, som jeg tildeler det inderste udtryk, og som jeg bruger til at
> referere til det, som var det en tabel.
>
> /Jan



Jan Bachman (04-01-2008)
Kommentar
Fra : Jan Bachman


Dato : 04-01-08 18:55

On Thu, 3 Jan 2008 20:05:01 +0100, "Henrik" <ha@spam.dk> wrote:

>Har søgt lidt på nettet inden jeg skrev her.
>men jeg forstår det stadig ikke, bruger du "nest" som et fiktiv navn?
>
>Prolemet er at jeg ikke kan få din søge sætning til at virke
>Det er nogle data som jeg skal hente ud af en gammel mysql database, og til
>det formål har jeg fundet et program der hedder urSQL, ved ikke om det er
>programmet der ikke kan finde ud af det, eller om jeg ud og søge efter noget
>andet.

Hver database har sin egen dialekt af SQL.
Det kan være du i MySQL skal have "AS" ind ved tildeling af alias.

Dvs.
inner join (bla bla) AS nest

/Jan

Søg
Reklame
Statistik
Spørgsmål : 177577
Tips : 31968
Nyheder : 719565
Indlæg : 6409071
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste