[lubic]

Om man tar bort syntax-felen i min fråga blir den som nedan:

select * from
(
select u.UserID userID1, u2.UserID userID2

from EventUsers eu
join Users u on u.UserID = eu.EventUserID

join EventUsers eu2 on eu2.EventUserID != eu.EventUserID
AND eu2.EventGender = u.UserGender AND eu2.EventCity = u.UserCity

join Users u2 on u2.UserID = eu2.EventUserID
AND u2.UserGender = eu.EventGender
AND u2.UserCity = eu.EventCity

order by RAND()
) q1 group by userID1

Dock så tänkte jag inte riktigt rätt i och med att min fråga gör så att user A kan matchas ihop med user B, samt att user C också kan matchas ihop med antingen user A eller user B, vilket gör att en och samma person kan vara med i flera olika par.

Någon annan får helt enkelt tänka istället för mig, så kanske det blir bättre

[JesperA]

Ursprungligen postat av rhdf

Ja, men du slipper 1000 anrop till databasen, vilket jag uppfattade var ditt största problem.

Jag ber om ursäkt, du hade helt rätt ända från början, det var mitt fel att jag inte gick vidare med din idé för det är sällan jag använder så stora arrayer & matchar arrayer med arrayer & modifierar & manipulerar dessa så jag hade svårt att visualisera konceptet men det är såklart bästa vägen att gå verkar det som (mer om det senare)

Ursprungligen postat av lubic

Om man tar bort syntax-felen i min fråga blir den som nedan:

Dock så tänkte jag inte riktigt rätt i och med att min fråga gör så att user A kan matchas ihop med user B, samt att user C också kan matchas ihop med antingen user A eller user B, vilket gör att en och samma person kan vara med i flera olika par.

Någon annan får helt enkelt tänka istället för mig, så kanske det blir bättre

Japp jag skall testa din query & se hur den presterar



Iaf, Alex slängde ihop en lösning som är i samma linje som rhdf:s förslag & prestandan är rejält förbättrad jämfört med min utgångspunkt:

1000 medlemmar tar 300ms att matcha istället för 3'000ms, 10ggr snabbare alltså :P

Första testerna jag körde så såg det ut att vara linjär ökning i exec tid motsvarande ökningen av event deltagare men det blir det ju såklart inte :P Ökar fortfarande exponentiellt och det tror jag inte man kan komma ifrån, tror aldrig att man kan få linjär skalning vid den här typen av matchning. Kanske lubic:s fungerar men har inte testat än.

Exponenten (fel terminologi tror jag men skit samma, ni förstår ändå), Alex version jämfört med min:

4000 medlemmar tar 5'200ms att matcha istället för 60'000ms, 10+ggr snabbare igen.

Så japp, det är mycket snabbare att leka med arrayen & köra logiken i PHP istället för att använda databasen för att sköta matchningen & begränsa så att samma användare inte blir dubletter i EventMatches.


Iaf, ursäkta att jag tjötar mer än postar kod men kommer inte hem förräns söndag & har begränsade möjligheter att testa under tiden, skall börja om igen på söndag & se om jag kan göra en egen version som kan matcha Alex:s version.

Tack för svaren allihopa sålänge iaf