[sql] max lukt wel, maar dan nog extra data erbij

[TiG]

Ik heb nu:

code:

SELECT topics.id
,   topics.subject
,   MAX(posts.time)
FROM topics
,    posts
WHERE posts.topic = topics.id
GROUP BY posts.topic

Dit werkt goed, maar nu zou ik ook graag het id hebben van de user die als laatste had gepost. Ik probeer dus dit:

code:

SELECT topics.id
,   topics.subject
,   MAX(posts.time)
,   posts.poster
FROM topics
,    posts
WHERE posts.topic = topics.id
GROUP BY posts.topic

Maar nu krijg ik niet het id van de lastposter maar gewoon van de 1e die bij dat topic hoort. Ik heb nog van alles geprobeert o.a. door wat met WHERE te zitten klooien (b.v. WHERE posts.time = MAX(posts.time)) maar dat werkte allemaal niet. Weet iemand hoe ik dit wel goed werkend kan krijgen?

[ACM]

select blabla ... group by bla having max(posts.time) ?

[TiG]

Dan krijg ik helemaal geen rows meer terug

[Erik Jan]

Je pakt het verkeerd aan, als MySQL in de table posts zoekt naar MAX(posts.time) geeft ie 1 waarde terug, omdat er maar 1 de hoogste is. Die wordt dus niet gerelateerd aan een bepaald record. Je kan dus zo ook niet het bijbehorende UserID krijgen, omdat er geen relatie MAX(posts.time)->posts.poster bestaat.

Een veel betere/snellere aanpak zou zijn om gewoon twee nieuwe fields te maken in je topics table. Dan krijg je gewoon zoiets als dit:

code:

SELECT topics.id,topics.subject,topics.lastposter,topics,lastposttime FROM topics

Helaas is dit geen antwoord op je vraag, ik ben niet zo'n kei in SQL

[TiG]

Ja, ik snap dat MAX() alleen maar 1 waarde terug geeft en dat er geen verband is. Maar het moet toch wel met 1 query kunnen zonder dat ik extra velden aan moet maken. Want dat laatste lijkt me nou niet echt het voorbeeld van een genormaliseerde databasestructuur

[Erik Jan]

TiG:
Want dat laatste lijkt me nou niet echt het voorbeeld van een genormaliseerde databasestructuur

Het is maar waar je je prioriteiten legt. Heb jij liever ranzige (?) SQL-query's en traag ladende topiclists, dan moet je afwachten of iemand die query voor je heeft.

Doe je liever net zoals alle grote spelers op het forumsoftware-gebied, dan zorg je er voor dat topics.lastposter, topics.replies etc. bij elke post in een topic geupdate worden en lees je die topiclist in een supersnel tempo uit.

[TiG]

Ik zou toch graag die query weten. Het lukt me echt niet. Iemand die me kan helpen?

[justmental]

Posts is de tabel waarover je groepeert.
Je moet dus beslissen welk record je wilt hebben uit die groepering.

[TiG]

Hoe kan ik bepalen welk record ik uit die groepering wil hebben? Ik krijg altijd de eerste en ik wil natuurlijk die hebben met de hoogste timestamp.

[Goodielover]

Op zondag 14 april 2002 20:40 schreef TiG het volgende:
Ik zou toch graag die query weten. Het lukt me echt niet. Iemand die me kan helpen?

Jawel, Ik!

Het is goor, maar werkt als een trein:

code:

select left(MAX(concat(posts.time,posts.poster)),#lengtetimeveld) Posttime
     substring(MAX(concat(posts.time,posts.poster)),#lengtetimeveld+1) Poster

Je concateneert dus eerst het record, dan neem je de max en dan haal je de info weer met stringfuncties (LEFT & SUBSTRING) uit elkaar.
De volgorde van je concatenatie is dus de sorteervolgorde van je velden. Als je varchar velden gaat concateneren, dan wel eerste even rpad-den om te voorkomen dat je sortering/max verkeerd uitpakt. Alleen het laatste veld hoef je niet de rpad-den.

[xoror]

Op zondag 14 april 2002 17:11 schreef TiG het volgende:
Ja, ik snap dat MAX() alleen maar 1 waarde terug geeft en dat er geen verband is. Maar het moet toch wel met 1 query kunnen zonder dat ik extra velden aan moet maken. Want dat laatste lijkt me nou niet echt het voorbeeld van een genormaliseerde databasestructuur

sorry dat ik dit omhoog kick, maar ik ben tegen hetzelfde aangelopen.

kijk bij AVG(), SUM(), COUNT() kan ik me voorstellen dat er dan geen verband meer is. Bij MIN(), MAX() echter is er toch wel een verband af te leiden. je selecteert immers resp. laagste en hoogste waarde van een column.

ik snap niet dat de makers van mysql dit niet fatsoenlijk kunnen implementeren.

zeker weer speed over functionaliteit...

[mocean]

Op zaterdag 01 juni 2002 19:10 schreef xoror het volgende:

[..]

sorry dat ik dit omhoog kick, maar ik ben tegen hetzelfde aangelopen.

kijk bij AVG(), SUM(), COUNT() kan ik me voorstellen dat er dan geen verband meer is. Bij MIN(), MAX() echter is er toch wel een verband af te leiden. je selecteert immers resp. laagste en hoogste waarde van een column.

ik snap niet dat de makers van mysql dit niet fatsoenlijk kunnen implementeren.

zeker weer speed over functionaliteit...

Verschil is heel simpel. Bij een standaard SELECT query selecteer je een of meerdere records. Bij de functies AVG, SUM, COUNT, MIN, MAX is niet een bepaald record gemoeid, maar wordt een interpretatie gedaan van bepaalde data. bedenk dat max en min ook werken wanneer er meerdere records zijn met dezelfde maximale of minimale waarde.

[xoror]

jah maar dan weet je toch nog steeds welke waarden bij de betreffende row horen (bij min en max dan).
Ook al zijn er dubbele waarden in een kolom, dan nog weet je uit welke row die max, min kwam.

het is gewoon bezopen dat je nu zo gore oplossing als goodielover moet gebruiken. (of 2+ queries)

[ACM]

Op zaterdag 01 juni 2002 19:19 schreef xoror het volgende:
het is gewoon bezopen dat je nu zo gore oplossing als goodielover moet gebruiken. (of 2+ queries)

Kan postgresql het wel?
Of informix?

[xoror]

ik double check zo na het eten wel. will report later

[ACM]

Op zaterdag 01 juni 2002 19:30 schreef xoror het volgende:
ik double check zo na het eten wel. will report later

Ik krijg hem zo gauw niet aan de praat.
Dan krijg je (bij mij iig) de boel PER poster per topic en echt zinvol lijkt dat me niet

In postgres kan je dan gelukkig deze doen
Wat nog es vrijwel net zo snel is uit te voeren volgens explain analyze ook

code:

SELECT T.id
,   T.subject
,   posts.poster
,   posts.time
FROM topics T
,    posts
WHERE posts.topic = T.id
and posts.time = (select max(posts.time) from posts where posts.topic = T.id)

[xoror]

pgsql kan het ook niet.
maar zoals je aangaf, kan je wel met sub-query oplossen, of zelf stored proc.

blijft vervelend.


(ps: pas op met aggregatie functies zoals count i.c.m mvcc
van pgsql en grote tabellen)

[ACM]

Op zondag 02 juni 2002 12:39 schreef xoror het volgende:
(ps: pas op met aggregatie functies zoals count i.c.m mvcc
van pgsql en grote tabellen)

mvcc