[SQL] top 10 rating berekenen

[Anoniem: 77516]

Beste tweakers,

probleem
Ondanks het programeren van mijn site erg goed gaat en ik al aardig wat leden heb, had ik het idee gekregen om een top 10 te maken.
Ik dacht zelf dat dit veel simpeler was dan het daadwerkelijk is.

Kolummen
De top 10 moet in verhouding zijn met de volgende kolommen uit de database:

- [ bezoekers ]
- [ rating ] (is een decimaal 0.000)
- [ aantal stemmen ]

Wat heb ik gebrobeerd?
Ik zat te denken om in de query een eis te maken dat er minimaal 10 keer gestemt moet worden en dat het profiel minimaal 10 bezoekers gehad moet hebben.
En vervolgens sorteren op rating.

Maar dit zal geen eerlijke resultaten geven lijkt mij, omdat iemand met 50 stemmen en een rating van 7.666 heeft eerste zal staan en iemand met 100 stemmen en een rating van 7.555 tweede zal staan.

Dit zal veel ruzies onderling veroorzaken

Vraag
Er is vast wel iemand hier op het forum die me kan sturen naar een goede query die eerlijkere resultaten terug zal geven.
Dus mijn vraag luidt, Welke oplossingen kunnen de eerlijkste resultaten bieden?

Ik dank iedereen alvast hartelijk

[dusty]

Het eerlijkst? Alleen zelf stemmen

Daarnaast is het systeem van het gemiddelde aardig eerlijk. ( Immers is 7.666 hoger dan 7.555 )

Als je een formule maakt door de laagste stem en hoogste stem die een persoon heeft uitgesproken, en die naar een gemiddelde omzet en daarop een balans uit laat voeren, kijken hoeveel "pieken" er in zitten, die eruit filteren, de gemiddelde omzetten in een aardig gemiddelde, zodat iemand die alleen maar tussen 6 en 8 stemmen uitbrengt ongeveer hetzelfde stemt als iemand die alleen maar stemmen tussen de 8 en de 10 uitbrengt.

Op zich een leuk systeem om te maken, maar of het uberhaupt ooit echt "eerlijk" is kan ik het antwoord al geven : Nee. Het blijft altijd subjectief, dus oneerlijkheid zal altijd blijven bestaan.

[Anoniem: 35839]

Waarom probeer je niet een aantal punten toe te kennen per stem (bijv een schaal van 1-5).
Iemand met weinig stemmen heeft dan wel een hoog percentage maar niet genoeg stemmen. Als je dan je rating in perc wilt uitdrukken kun je de verhoudingen op het punten aantal loslaten.

[Anoniem: 77516]

Heey dat klinkt als een goede oplossing ja..

Maar je bedoelt dus:
Dat gebruikers elkaar punten geven, en dat die punten in een kolom opgetelt worden.

Als ik het gemiddelde wil hebben dan ik het aantal stemmen in totaal punten..

Alleen snap ik niet echt met wat voor query ik moet maken om te zorgen dat ik een top10 krijgt.. Zou je daarin misschien iets specifieker kunnen zijn?

Maar uiteraards alvast bedankt!

[Max|Burn]

ik denk zoals je het nu doe het toch niet zo erg verkeerd is hoor..
Het gaat om het gemiddelde en iemand met 50 votes (7.666) staat toch echt boven iemand met 7.55
Denk aan tennis, een tenniser met een hoge rating hoeft niet per se al 20 jaar (x tig wedstrijden)te tennissen
Een tennisser die 2 jaar lang goed presteerd wordt eerste

[P_de_B]

MaxBurn schreef op 13 april 2004 @ 13:37:
ik denk zoals je het nu doe het toch niet zo erg verkeerd is hoor..
Het gaat om het gemiddelde en iemand met 50 votes (7.666) staat toch echt boven iemand met 7.55
Denk aan tennis, een tenniser met een hoge rating hoeft niet per se al 20 jaar (x tig wedstrijden)te tennissen
Een tennisser die 2 jaar lang goed presteerd wordt eerste

Wat TS denk ik bedoelt is dat iemand die 1 keer een 8 heeft gekregen boven iemand staat die 1321 keer een 7.8 heeft gekregen. Ik denk dat als je dit wilt meenmemen je ook een bepaalde waarde aan het aantal stemmen moet hangen. Hoe hangt af van het feit hoe zwaar je het aantal stemmen ten opzichte van de waarde wilt laten meetellen.

[Pinobigbird]

P_de_B schreef op 13 april 2004 @ 13:39:
[...]


Wat TS denk ik bedoelt is dat iemand die 1 keer een 8 heeft gekregen boven iemand staat die 1321 keer een 7.8 heeft gekregen. Ik denk dat als je dit wilt meenmemen je ook een bepaalde waarde aan het aantal stemmen moet hangen. Hoe hangt af van het feit hoe zwaar je het aantal stemmen ten opzichte van de waarde wilt laten meetellen.

Dan zou je er voor kunnen kiezen alleen gebruikers met meer dan 10 stemmen mee te nemen. (of 20, of 50, wat je zelf een hoog genoeg aantal vindt)
Dat iemand met 100/7.555 lager staat dan 50/7.666 vind ik overigens terecht, zie de redenatie van MaxBurn

[Anoniem: 77516]

De methode van "snapnie" lijkt me de beste, maar ik weet niet echt hoe ik dan een query moet maken die er een top 10 uit laat rollen.

Heeft iemand hier misschien een idee voor?
avlast bedankt.

[BestTested!]

Wat misschien ook een oplossing is, is om een soort gewogen gemiddelde te maken. Waarbij het aantal stemmen dat iemand heeft gekregen met een bepaalde factor verhoogt wordt, waardoor er een nieuwe score uitkomt. Die factor zou je bijvoorbeeld kunnen laten afhangen van alle stemmen op alle objecten tesamen.

Voorbeeld:

code:

A heeft 100 stemmen gekregen met een gemiddelde van 7.5
B heeft 50  stemmen gekregen met een gemiddelde van 7.7
C heeft 10  stemmen gekregen met een gemiddelde van 9.0  

Totaal: 160 stemmen

Score A: (1 + (100/160)) * 7.5 = 12,1875
Score B: (1 + (50 /160)) * 7.7 = 10.10625
Score C: (1 + (10 /160)) * 9.0 = 9.5652

Of dit nou zo eerlijk is moet je zelf bepalen. Iemand met een hoger gemiddelde maar met minder stemmen zou op deze manier kunnen verliezen van iemand met een lager gemiddelde maar met meer stemmen mits het verschil in stemmen groot genoeg is.

[Wolfboy]

BestTested! schreef op 13 april 2004 @ 20:20:
Wat misschien ook een oplossing is, is om een soort gewogen gemiddelde te maken. Waarbij het aantal stemmen dat iemand heeft gekregen met een bepaalde factor verhoogt wordt, waardoor er een nieuwe score uitkomt. Die factor zou je bijvoorbeeld kunnen laten afhangen van alle stemmen op alle objecten tesamen.

Voorbeeld:

code:

A heeft 100 stemmen gekregen met een gemiddelde van 7.5
B heeft 50  stemmen gekregen met een gemiddelde van 7.7
C heeft 10  stemmen gekregen met een gemiddelde van 9.0  

Totaal: 160 stemmen

Score A: (1 + (100/160)) * 7.5 = 12,1875
Score B: (1 + (50 /160)) * 7.7 = 10.10625
Score C: (1 + (10 /160)) * 9.0 = 9.5652

Of dit nou zo eerlijk is moet je zelf bepalen. Iemand met een hoger gemiddelde maar met minder stemmen zou op deze manier kunnen verliezen van iemand met een lager gemiddelde maar met meer stemmen mits het verschil in stemmen groot genoeg is.

op die manier zal iemand die dus meer votes heeft bijna altijd een hogere score krijgen, dat lijkt me helemaal niet eerlijk eigenlijk

mij lijkt het toch de beste oplossing om gewoon uit te rekenen wat het gemiddelde is en onder de 10 stemmen niet toelaten ofzo
en dan er gewoon bij zetten hoeveel votes er totaal zijn geweest zodat mensen kunnen zien waarom iets hoger of lager staat

[BestTested!]

Wolfboy schreef op 13 april 2004 @ 21:18:
[...]
op die manier zal iemand die dus meer votes heeft bijna altijd een hogere score krijgen, dat lijkt me helemaal niet eerlijk eigenlijk

mij lijkt het toch de beste oplossing om gewoon uit te rekenen wat het gemiddelde is en onder de 10 stemmen niet toelaten ofzo
en dan er gewoon bij zetten hoeveel votes er totaal zijn geweest zodat mensen kunnen zien waarom iets hoger of lager staat

Klopt inderdaad jah. Even snel wat rekenwerk gedaan; die factor doet 't 'm. Wanneer je die factor ( 1 + ( 100/160) ) minder zou kunnen laten wegen klopt het iets beter. Dan krijg je bijvoorbeeld:

Score A: (((1 + (100/160)) * 7.5) + (9 * 7.5)) / 10 = 7.9687

Zo wordt iemand zeg maar ´beloond´ voor het feit dat hij meer stemmen heeft, maar de invloed van deze beloning wordt beperkt omdat hij slechts een factor 1 heeft tegenover de factor 9 van het eigenlijke punt.

[cameodski]

BestTested! schreef op 13 april 2004 @ 21:39:
Zo wordt iemand zeg maar ´beloond´ voor het feit dat hij meer stemmen heeft, maar de invloed van deze beloning wordt beperkt omdat hij slechts een factor 1 heeft tegenover de factor 9 van het eigenlijke punt.

En als nu heel veel mensen iemand slecht beoordeeld hebben, omdat ie zo'n ontzettend grote klungel is?
Betekent dat dan dat ie doordat hij zo slecht beoordeeld is, hoger komt te staan?
Als het goed is, komt hij dan natuurlijk helemaal niet in de top 10 voor, maar als er nou eens heel veel op hem gestemd hebben, gaat dat waarschijnlijk toch wel meewegen.
En als het niet gaat meewegen, kan het wel eens zijn, dat er niet bereikt wordt, wat je wil en dat degene met 50 iets hogere stemmen toch boven degene met 100 wat lagere stemmen komt te staan.

Ik denk, zoals al eerder genoemd is, dat je het beste de mensen met weinig stemmen weg kunt laten.

[ Voor 26% gewijzigd door cameodski op 13-04-2004 22:05 ]

[Anoniem: 77516]

Ik heb al een manier bedacht met dank aan "snapnie"

Ik maak gewoon een kolom met het aantal punten dat een gebruiker heeft gekregen.

Als ik het percentage wil hebben doe ik:
punten/stem_aantal

En nummer 1 is uiteraard degene met de meeste punten

Zeg maar hoe jullie over dit idee denken.. En als je iets niet snapt zal ik het fijner uitleggen..

[dusty]

Dus iemand die 100 keer 5 punten krijgt wint van iemand die 49 keer 10 punten krijgt ?

[Anoniem: 77516]

Ja, oke maar met een punten systeem lijkt me veiliger, want dan kunnen mensen elkaar niet omlaag stemmen...

[Anoniem: 35839]

Waarom neem je niet het percentage van de behaalde punten als meet instrument?

Dus iemand die 50 x 10 punten krijgt tegen iemand die 100 x 5 punten krijgt is dan gelijkt.

50 x 10 = 500 / totaal punten=500/1000=0.5
100 x 5 = 500 / totaal punten = 500/1000=0.5

Dus het aantal stemmen wat je haalt is dan niet belangrijk.

Ik weet waarvoor gestemt kan worden, maar zo elimineer je wel personen die stemmen buiten de doelgroep. En kan een piek of dal waarde tot een minimum worden gehouden.

In een query kun je dit ophalen met een group by vooraf gaand een sum.
bijv.(effe uit mijn hoofd)
select naam, (sum(punten)/total)*100 as perc from table1, (select sum(punten) as total from table1)temp group by naam order by perc desc

PS:
voor subselect wel effe mysql 4.1.x downen

[ Voor 4% gewijzigd door Anoniem: 35839 op 14-04-2004 10:16 ]

[Anoniem: 77516]

Beste Mensen,

Ik weet dat dit topic meer als een jaar oud is, maar ik ben er nog steeds mee bezig (na 1 jaar) kwam ik weer met hetzelfde (probleem?). Mocht een van de admins/modjes willen dat ik een nieuw topic start is dat ook goed.

Ik ben al een tijdje bezig met een ander profielen systeem, waarop je ook kan stemmen (met een cijfer 1 t/m 10 ).
Ik heb er samen met mijn vader overgehad ( hij is wiskunde freak ) en samen hebben we een formule ontworpen.

Maargoed we hebben een profielen systeem, en met de volgende middelen kunnen we een top 10 laten afwegen:
- het aantal stemmen per gebruiker/totaal (per maand)
- het gemiddelde per gebruiker/totaal (per maand)
- het aantal (unieke) bezoekers per gebruiker/totaal en per maand

Maargoed met deze gegevens heeft mijn vader een formule ontworpen:

code:

((A X B / Som(B) X 0.2)
+
(A X D / (Som(D) ) 
X
(C / Som(C))
X
0.8

##Legenda

A   = alle gebruikers gestemt huidige maand, per gebruiker
Som(A)  = alle gebruikers gestemt huidige maand
B   = Aantal bezoekers huidige maand, per gebruiker
Som(B)  = Aantal bezoekers huidige maand
C   = SOM van rating per gebruiker huidige maand
Som(C)  = SOM van rating totaal, huidige maand
D   = Aantal stemmen per gebruiker
Som(D)  = Aantal stemmen totaal

Met deze formule laten we dus het aantal bezoekers/stemmen ook meetellen en kan ik zelf instellen hoe zwaar. Deze formule leek me erg goed en ging het verbouwen in een query

PHP:

$sum_a  = mysql_num_rows( query_result( 'SELECT id FROM '.$table['rates'].' WHERE month="'.date('m').'"') );
$sum_b  = mysql_fetch_object( query_result( 'SELECT SUM(`'.date('m').'`) AS total_views FROM '.$table['pageviews'] ));
$sum_b  = $sum_b->total_views;
$sum_c  = mysql_num_rows( query_result( 'SELECT id FROM '.$table['rates'] ) );
$sum_d  = mysql_fetch_object( query_result( 'SELECT AVG( rate ) AS total_rate FROM '.$table['rates'].' WHERE month="'.date('m').'"'));
$sum_d  = $sum_d->total_rate;
$result = query_result( 'SELECT
                                u.username,
                                ((COUNT(r.id) * p.'.date('m').' / '.$sum_b.' * 0.2)
                                +
                                 (COUNT(r.id) * COUNT(r.id)
                                ';




####LEGENDA#############
##r = rate table                   ##
##u = user table                 ##
##p = pageviews table        ##
#########################

Opzich lijkt het me realiseerbaar, maar ik liep vast op SOM(D) en D. Waarom? Omdat A en SOM(A) eigenlijk hetzelfde zijn. Maar deze zijn per maand. Dus nou zat ik te denken, als ik SOM(A) bijvoorbeeld gebruik moet ik dus bij het criterium zetten (WHERE month=dezemaand). Dit levert dus het probleem op dat hij dan SOM(D) of D ook vandeze maand pakt lijkt me.

Maargoed, mijn vragen zijn eigenlijk,
is de formule realiseerbaar in een query?
hoe ga ik het oplossen met de SOM(A) en SOM(D) ?
Heeft iemand nog tips/suggesties over de formule?
En kan iemand me ook opweg helpen met me query

tabel ontwerpjes
Ik gebruik de volgende tabellen in mijn database
Rating tabel
- id INT( 5) primary key
- regdate INT(10)
- month INT(2)
- src_id INT(5)
- des_id INT(5)
- rate INT(2)

Pageviews
- src_id INT(5) primary key
- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- year INT(4)
Allee maanden zijn INT(5).
Allemaal draaiend op MySQL 4.0.18


Alvast bedankt voor de hulp

[ Voor 5% gewijzigd door Anoniem: 77516 op 01-07-2005 09:02 ]

[dusty]

Anoniem: 77516 schreef op vrijdag 01 juli 2005 @ 09:01:
[..]
Maargoed, mijn vragen zijn eigenlijk,
is de formule realiseerbaar in een query?
hoe ga ik het oplossen met de SOM(A) en SOM(D) ?
Heeft iemand nog tips/suggesties over de formule?
En kan iemand me ook opweg helpen met me query
[..]

1) Ja de Formule is realiseerbaar.
2) Som(A) wordt niet gebruikt in de formule, de hint voor je oplossing is: select a.id,sum(b.id) from MyTabel a, MyTabel b where a.customer=b.customer and a.month=1
3) Waarom loont het spammen van je profiel?
4) Tuurlijk: het eerste woordje is SELECT

[Anoniem: 77516]

hmz als ik het goed begrijp moet ik dan gewoon hetzelfde tabel in de FROM zetten en dan een andere alias geven, zodat hij niet opgenomen wordt in de criterium?

[dusty]

Anoniem: 77516 schreef op vrijdag 01 juli 2005 @ 12:56:
hmz als ik het goed begrijp moet ik dan gewoon hetzelfde tabel in de FROM zetten en dan een andere alias geven, zodat hij niet opgenomen wordt in de criterium?

Yup.

[Anoniem: 77516]

Oke mensen, ik heb gebeunt en gesleuteld en ben tot de volgende query gekomen:

SQL:

SELECT
        `user`.`username`,
        ( COUNT(`rates`.`id`) * `pageviews`.`07` / SUM(`pageviews2`.`07`) * 0.2 )
        +
        ( COUNT(`rates`.`id`) * COUNT(`rates2`.`id`) / COUNT(`rates3`.`id`) )
        *
        ( SUM(`rates`.`rate`) / SUM(`rates2`.`rate`) ) * 0.8 AS `score`
FROM    `scoot_rates` AS `rates`,
        `scoot_rates` AS `rates2`,
        `scoot_rates` AS `rates3`,
        `scoot_pageviews` AS `pageviews`,
        `scoot_pageviews` AS `pageviews2`,
        `scoot_users` AS `user`
WHERE
        `rates`.`month`="07"
AND     `user`.`id`=`rates`.`src_id`
AND     `user`.`id`=`pageviews`.`src_id`
AND     `user`.`id`=`rates2`.`src_id`
GROUP BY `user`.`username`,`pageviews2`.`07`
ORDER BY `score` DESC
LIMIT 10;

Volgens een goede vriend van mij zou deze query wel kloppen, maar zodra ik hem execute raakt mysql helemaal van slag, en krijgt hij hem niet geexecute en crashed zelfs apache althans dat lijkt (hele website werkt dan eventjes niet meer) en zodra mysql gereset wordt dan werkt alles pas weer.

Ik heb ook explain gebruikt en dit gaf het volgende resultaat:


sorry for the bad quality .. klik op de foto voor een vergroting

Wie o Wie gaat voor de super troffee en helpt me

BTW: het gaat om mySQL 4.0 nog wa

[ Voor 3% gewijzigd door Anoniem: 77516 op 08-07-2005 21:52 ]

[Anoniem: 74701]

Dit is wat men noemt een 'Query from Hell'

Als je in je from clause 2 tabellen zet (rates3 en pageviews2) en deze niet in je where clause gaat gebruiken, krijg je een cartesische product.
Wat je volgens mijn niet kan, is je formule in 1 query steken in MySQL 4.0. Het zal je wel lukken als je met MySQL 4.1 met behulp van subqueries de query gaat 'beunen'.

[Anoniem: 77516]

Anoniem: 74701 schreef op maandag 04 juli 2005 @ 11:08:
Dit is wat men noemt een 'Query from Hell'

Als je in je from clause 2 tabellen zet (rates3 en pageviews2) en deze niet in je where clause gaat gebruiken, krijg je een cartesische product.
Wat je volgens mijn niet kan, is je formule in 1 query steken in MySQL 4.0. Het zal je wel lukken als je met MySQL 4.1 met behulp van subqueries de query gaat 'beunen'.

"query from hell" wilt dat zeggen dat ik een waardeloze programmeur ben

Maargoed mysql 4.1 erop zetten zit er waarschijnlijk niet in, maar ik hoop wel een goede oplossing

Als ik nu alle niet gebruiker gerelateerde results (dus alle stemmen totaal van de maand, alle bezoekers totaal etc) in vars wegschrijf in php dus in aparte query's zou mijn mysql dan niet crashen?

[Anoniem: 77516]

*neemt aanloop* .... *geeft een keiharde schop.. en scoort!!!*

uhh.. anyone can help me?

[Anoniem: 74701]

Anoniem: 77516 schreef op maandag 04 juli 2005 @ 15:19:
Als ik nu alle niet gebruiker gerelateerde results (dus alle stemmen totaal van de maand, alle bezoekers totaal etc) in vars wegschrijf in php dus in aparte query's zou mijn mysql dan niet crashen?

Ik denk dat je dit zeker eens moet proberen, lijkt mij een goede oplossing.

[Anoniem: 77516]

Nou mensen het bovenstaan heb ik dus geprobeerd. (totaal resultaten in aparte query's gezet) maar iets klopt er nog niet omdat de getallen waarmee de query rekent helemaal niet kloppen.

Top 10 query

SQL:

SELECT
`user`.`id` ,
`user`.`username` ,
`pageviews`.`07` AS views_maand,
SUM(rates.rate) AS rate_maand,
SUM(rates2.rate) AS rate_totaal,
COUNT( rates.month ) AS stem_maand,
COUNT( rates2.id ) AS stem_totaal,
AVG( rates.rate ) AS avg_maand,
AVG( rates2.rate ) AS avg_totaal,
(
COUNT( `rates`.`id` ) * `pageviews`.`07` /1309 * 0.2
) + ( COUNT( `rates`.`id` ) * COUNT( `rates2`.`id` ) /1460 ) * ( AVG( `rates`.`rate` ) / AVG( `rates2`.`rate` ) ) * 0.8 AS `score`
FROM `scoot_rates` AS `rates` , `scoot_rates` AS `rates2` , `scoot_pageviews` AS `pageviews` , `scoot_users` AS `user`
WHERE `rates`.`month` = "07"
AND `user`.`id` = `rates`.`des_id`
AND `user`.`id` = `pageviews`.`src_id`
AND `user`.`id` = `rates2`.`des_id`
GROUP BY `rates`.`des_id`
ORDER BY `score` DESC
LIMIT 10

Geeft het volgende resultaat:


Zoals je ziet (als je het vergelijkt met de volgende query) zie je dat de waarden waarmee hij rekent enorm groot zijn, en kloppen voor geen meter. Zowiezo zie je dat het aantal stemmen van deze maand en het aantal stemmen in totaal precies hetzelfde zijn. (kolom 6 en 7) Het zelfde geld voor kolom 4 en 5.

Query 2
Gaan we alles selecteren maar dan zonder berekening, krijgen we wel eerlijke cijfers:

SQL:

SELECT
        scoot_users.id,
        scoot_users.username,
        scoot_pageviews.`07` AS bezoekers_juli,
        COUNT(scoot_rates.id) as aantal_stemmen_juli,
        SUM(scoot_rates.rate) AS rating,
        AVG(scoot_rates.rate) AS gemiddelde_rating_juli
FROM    `scoot_rates`,
        `scoot_users`,
        `scoot_pageviews`
WHERE   scoot_users.id=scoot_rates.des_id
AND     scoot_users.id=scoot_pageviews.src_id
AND     scoot_rates.month=7
GROUP BY scoot_rates.des_id
ORDER BY aantal_stemmen_juli
DESC LIMIT 10

Zoals je ziet zijn de getallen kleiner. Ik denk dat het probleem een group by probleem is ofzo, maar ik groeppeer wel per gebruik (GROUP BY des_id (destination_id) ) .

Overigens zie je ook dat mensen die meer stemmen hebben sneller bovenaan komen te staan, ik had het uitgetest en ik stemde een 1 op iemand en die ging omhoog in de top 10 dat klopt volgens mij ook niet.. dus het aantal stemmen telt zwaarder mee, maar waarschijnlijk ligt dat dan aan query fout??

Iemand enig idee waar het aan zou kunnen liggen?

Alvast erg bedankt!

[Anoniem: 77516]

kick

[mrFoce]

Anoniem: 77516 schreef op vrijdag 08 juli 2005 @ 12:46:
kick

niet kicken binnen 24 uur, ga wat sql boeken lezen om de tijd te doden ofzo

en het aantal stemmen telt zwaarder mee omdat je dit gebruikt -> ORDER BY aantal_stemmen_juli

ik dacht dat je ook kon 'ORDEREN' op 2 velden door BV ORDER BY aantal_stemmen_juli, aantal_stemmen_juni te gebruiken

[ Voor 39% gewijzigd door mrFoce op 08-07-2005 13:00 ]

[Anoniem: 77516]

nee ben helaas geen SQL boek aan het lezen, wel andere documentatie...

Maargoed, het gaat ook niet om de 2e query die is puur om te vergelijken en te zien dat het niet klopt. Zoals je ziet dus Het gaat uiteindelijk om de 1e query

[mrFoce]

Anoniem: 77516 schreef op vrijdag 08 juli 2005 @ 13:13:
nee ben helaas geen SQL boek aan het lezen, wel andere documentatie...

Maargoed, het gaat ook niet om de 2e query die is puur om te vergelijken en te zien dat het niet klopt. Zoals je ziet dus Het gaat uiteindelijk om de 1e query

uhm


ORDER BY `score`,'avg_totaal' DESC al geprobeerd?

edit-> http://www.w3schools.com/sql/sql_orderby.asp

[ Voor 11% gewijzigd door mrFoce op 08-07-2005 13:21 ]

[Anoniem: 77516]

Dat hoef ik niet te proberen, omdat het primaire probleem dus is dat hij rekent met waarden die niet kloppen. Ik denk dat daarom de uitkomst ook vals is. Ik vermoed dat het een groeppeer fout is ofzo.. maar het rare is .. ik hoef eigenlijk per gebruiker te groeperen toch?

[Anoniem: 74701]

als ik het goed begrijp, weet je dat je 1e query fout is, maar je weet niet wat de juiste oplossing moet zijn. Om dit probleem op te lossen moet je een test database maken, waar je enkele records in steekt, zodat je op papier het resultaat kunt berekenen, daarna kan je zoveel queries 'beunen' totdat je het juiste resultaat hebt, zolang je gaat werken op een kopie van 'produktie' database, zal je nooit zeker zijn dat je resultaat juist is.

en zoals ik je al eerder zei, kan het resultaat niet in 1 query steken omdat je velden met als suffix 'maand' en suffix 'totaal' een andere group by clause nodig hebben

maand : group by des_id, month
totaal : group by month

dus maand totalen op voorhand berekenen en die waarden in je query gebruiken om je score te berekenen.

en dan ben je nog niet, want users zonder een rating in een maand zullen niet opgenomen worden in je query, die krijg je erbij als je ze OUTER JOINt.

Trouwens, zou je die score niet als veld in je user tabel steken, zodat je server niet overbelast wordt als enkele mensen samen de query uitvoeren.

[Mischa_NL]

ik blijf het onzin vinden dat je het aantal stemmen meetelt
Iemand met een hoger punt heeft een hoger punt, 1 stem of 10000 stemmen.

[Anoniem: 77516]

Anoniem: 74701 schreef op zaterdag 09 juli 2005 @ 14:56:
als ik het goed begrijp, weet je dat je 1e query fout is, maar je weet niet wat de juiste oplossing moet zijn. Om dit probleem op te lossen moet je een test database maken, waar je enkele records in steekt, zodat je op papier het resultaat kunt berekenen, daarna kan je zoveel queries 'beunen' totdat je het juiste resultaat hebt, zolang je gaat werken op een kopie van 'produktie' database, zal je nooit zeker zijn dat je resultaat juist is.

en zoals ik je al eerder zei, kan het resultaat niet in 1 query steken omdat je velden met als suffix 'maand' en suffix 'totaal' een andere group by clause nodig hebben

maand : group by des_id, month
totaal : group by month

dus maand totalen op voorhand berekenen en die waarden in je query gebruiken om je score te berekenen.

en dan ben je nog niet, want users zonder een rating in een maand zullen niet opgenomen worden in je query, die krijg je erbij als je ze OUTER JOINt.

Trouwens, zou je die score niet als veld in je user tabel steken, zodat je server niet overbelast wordt als enkele mensen samen de query uitvoeren.

Veel dank voor je reactie,

Zoals je kunt zien heb ik dus de totalen die niet gebruiker gerelateerd zijn in een aparte querry gedumpt. Dus alle sommaties etc die je nu ziet in de eerste query zijn dus per gebruiker. Echter vindt ik het zo vaag dat hij met grote aantallen werkt ..Terwijl die getallen nooit zo groot kunnen zijn.

BTW: test ik alles uit in een test databaseje ja ik heb de echte tabel al te vaak plat gegooit muahaha

Maar uhm, als ik dus de score in het user tabel wil zetten (1000 users) hoe kan ik dat dan het beste doen? Met een cronjob ofzo en dan de query om de 30 minuten laten uitvoeren en verwerken? (statistieken zijn dan niet realtime ).
En betreft die outer join, heb je gelijk maar ik heb een aantal tuts gelezen erover maar snap eigenlijk niet zo goed hoe je het moet gebruiken. Want moet ik dan joinen op elk tabel ofzo?

[Anoniem: 77516]

Mischa_NL schreef op zaterdag 09 juli 2005 @ 15:30:
ik blijf het onzin vinden dat je het aantal stemmen meetelt
Iemand met een hoger punt heeft een hoger punt, 1 stem of 10000 stemmen.

Het gaat er ook om hoe populair een scooter is, en geef toe als iemand 1 keer een 10 heeft gekregen hoeft hij niet meteen bovenaan te staan toch?

[mrFoce]

offtopic:
Je scooter forumpje gebruikt een 'warez' versie van IPB