DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Precies zo. Alleen dan nog eentje bij het resultaat optellen.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Oke, bedankt!quote:Op zondag 8 januari 2012 23:37 schreef GlowMouse het volgende:
Precies zo. Alleen dan nog eentje bij het resultaat optellen.
je houdt het trouwens wel lang vol om iemand niet het antwoord te geven, maar zelf te laten maken
Veel doeltreffender.quote:Op zondag 8 januari 2012 23:40 schreef dirkjo het volgende:
[..]
Oke, bedankt!
je houdt het trouwens wel lang vol om iemand niet het antwoord te geven, maar zelf te laten maken
Er is nu alleen wel één probleempje. Ik vertelde net dat die oude query mij dezelfde waarde geeft als wanneer ik de hele lijst zou echo'en. Deze doet dat nietquote:
Precies zo. Alleen dan nog eentje bij het resultaat optellen.
Je zei dat dat bij die oude query toevallig zo gebeurde, maar na een flink aantal refreshes blijft die lijst precies hetzelfde.
//edit
Deze manier geeft zelfs bij meerdere nummers dezelfde rank, terwijl dit toch echt iets is wat niet mag gebeuren
Dan moet je die andere lijst aanpassen zodat hij zo wordt:quote:
[..]
Er is nu alleen wel één probleempje. Ik vertelde net dat die oude query mij dezelfde waarde geeft als wanneer ik de hele lijst zou echo'en. Deze doet dat niet
1. song12 met een socore van 34
2. song3 met een socore van 24
2. song6 met een socore van 24
4. song3 met een socore van 3
En toch heb je geen garantie dat het niet verandert.quote:Je zei dat dat bij die oude query toevallig zo gebeurde, maar na een flink aantal refreshes blijft die lijst precies hetzelfde.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Je doet het nu door te selecteren op het aantal likes?quote:
[..]
Er is nu alleen wel één probleempje. Ik vertelde net dat die oude query mij dezelfde waarde geeft als wanneer ik de hele lijst zou echo'en. Deze doet dat niet
Je zei dat dat bij die oude query toevallig zo gebeurde, maar na een flink aantal refreshes blijft die lijst precies hetzelfde.
//edit
Deze manier geeft zelfs bij meerdere nummers dezelfde rank, terwijl dit toch echt iets is wat niet mag gebeuren
| 1 2 3 4 5 6 7 8 | SET @rownum := 0; SELECT * FROM ( SELECT @rownum := @rownum+1 AS song_rank, likes FROM songs ORDER BY likes DESC ) AS song_score WHERE songID = " . $songID |
Bovenstaande zou je de rank terug moeten geven adhv het songid.
[ Bericht 6% gewijzigd door The_Terminator op 09-01-2012 00:06:46 ]
Ik gebruik nu de manier van GM, een paar posts terug.quote:
[..]
Je doet het nu door te selecteren op het aantal likes?
[ code verwijderd ]
Bovenstaande zou je de rank terug moeten geven adhv het songid.
Wijzig
SELECT songID FROM songs ORDER BY `likes` DESC
in
SELECT songID FROM songs ORDER BY `likes` DESC,songID DESC
En
SELECT COUNT(*) AS rank FROM songs WHERE likes > ...
in
SELECT COUNT(*) AS rank FROM songs WHERE likes > ... OR (likes = .... ANDS songID > ....)
SELECT songID FROM songs ORDER BY `likes` DESC
in
SELECT songID FROM songs ORDER BY `likes` DESC,songID DESC
En
SELECT COUNT(*) AS rank FROM songs WHERE likes > ...
in
SELECT COUNT(*) AS rank FROM songs WHERE likes > ... OR (likes = .... ANDS songID > ....)
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ah, ok. Ik heb mijn code zojuist wat aangepast en getest. Het functioneerd goed en geeft de positie terug adhv een gegeven songID, zoals je dat in je eerste versie had.quote:
[..]
Ik gebruik nu de manier van GM, een paar posts terug.
Heldquote:
Wijzig
SELECT songID FROM songs ORDER BY `likes` DESC
in
SELECT songID FROM songs ORDER BY `likes` DESC,songID DESC
En
SELECT COUNT(*) AS rank FROM songs WHERE likes > ...
in
SELECT COUNT(*) AS rank FROM songs WHERE likes > ... OR (likes = .... ANDS songID > ....)
Dit gebruik ik nu en werkt:quote:
[..]
Ah, ok. Ik heb mijn code zojuist wat aangepast en getest. Het functioneerd goed en geeft de positie terug adhv een gegeven songID, zoals je dat in je eerste versie had.
| 1 2 3 | <?php $rankQuery = mysql_query("SELECT COUNT(*) AS rank FROM songs WHERE `likes` > ". $likes. " OR (`likes` = '". $likes ."' AND `songID` > ". $songID .")"); ?> |
Still, thanks.
Die van T_T werkt ook, maar die van mij is uiteraard sneller.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
True.quote:Op maandag 9 januari 2012 00:09 schreef GlowMouse het volgende:
maar die van mij is uiteraard sneller.
Als we dan toch over COUNT hebben. Is het verstandiger om gebruik te maken van de COUNT functie om te kijken of een user bestaat, dan gebruik je maken van mysql_num_rows? Ik gebruik nu die laatste, maar dit lijkt me (nu ik een beetje door heb hoe COUNT werkt) vrij omslachtig.
Dat is het inderdaad. Als jij een query zonder COUNT(*) doet dan gaan alle rijen van MySQL naar PHP zodat PHP ze kan tellen.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Oke, duidelijk!quote:
Dat is het inderdaad. Als jij een query zonder COUNT(*) doet dan gaan alle rijen van MySQL naar PHP zodat PHP ze kan tellen.
Ik heb de volgende query
Maar Percentage is dan tot 8 decimalen achter de komma. Kan ik dit eenvoudig beperken tot 2?
| 1 2 3 4 5 | SELECT Naam, Challenge, Voortgang, ( Voortgang / ( Challenge /100 ) ) AS Percentage FROM hardlopen ORDER BY Naam |
Maar Percentage is dan tot 8 decimalen achter de komma. Kan ik dit eenvoudig beperken tot 2?
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Ik had de 2e parameter bij ROUND gemist in mijn zoektocht, bedankt!quote:
round gebruiken.
http://www.w3schools.com/sql/sql_func_round.asp
Of http://php.net/manual/en/function.round.php in php als je de db server niet je rekenwerk wil laten doen
Ik zou dit soort taken niet bij de database server neerleggen. Queries moet je zo licht mogelijk schrijven, zodat je de database server zo min mogelijk lastig valt.quote:
Ja de op functie ken ik, maar in dit geval was het makkelijker in mysql.
Geloof me, m'n server krijgt het er echt niet warm vanquote:
[..]
Ik zou dit soort taken niet bij de database server neerleggen. Queries moet je zo licht mogelijk schrijven, zodat je de database server zo min mogelijk lastig valt.
Dat begrijp ik, maar het gaat er om dat je begrijpt waarom je die dingen daar niet moet neerleggenquote:Op dinsdag 10 januari 2012 10:43 schreef Swetsenegger het volgende:
[..]
Geloof me, m'n server krijgt het er echt niet warm van
Je kunt het je beter direct goed aanleren
Het is niet fout om je query zo te formuleren dat de data die eruit komt zo nuttig mogelijk is in je applicatie.quote:
[..]
Dat begrijp ik, maar het gaat er om dat je begrijpt waarom je die dingen daar niet moet neerleggen
Swets is al een paar stapjes verder dan aanlerenquote:
[..]
Dat begrijp ik, maar het gaat er om dat je begrijpt waarom je die dingen daar niet moet neerleggen
En ik ben het met Tijn eens. Het is niet per definitie fout om de DB server te laten rekenen.
Het is niet fout, maar kwa belasting wil je het gewoon niet. Bij hobby projecten maakt het uiteraard niets uit waar je het doet en als die het makkelijkste voor je is dan moet je het vooral doen. Maar als je grote projecten draait dan kunnen dit wel winst punten zijn.quote:Op dinsdag 10 januari 2012 10:50 schreef Tijn het volgende:
[..]
Het is niet fout om je query zo te formuleren dat de data die eruit komt zo nuttig mogelijk is in je applicatie.
Zelfde als in hobby projecten kun je best: SELECT * doen, maar het is beter om alleen de velden op te halen die nodig zijn.
Dat dus.quote:Op dinsdag 10 januari 2012 10:51 schreef GI het volgende:
[..]
Swets is al een paar stapjes verder dan aanleren
En ik ben het met Tijn eens. Het is niet per definitie fout om de DB server te laten rekenen.
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Definieer 'belasting'.quote:
[..]
Het is niet fout, maar kwa belasting wil je het gewoon niet. Bij hobby projecten maakt het uiteraard niets uit waar je het doet en als die het makkelijkste voor je is dan moet je het vooral doen. Maar als je grote projecten draait dan kunnen dit wel winst punten zijn.
Zelfde als in hobby projecten kun je best: SELECT * doen, maar het is beter om alleen de velden op te halen die nodig zijn.
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Als je round door je db-clients wilt laten uitrekenen, ben je verkeerd bezig.quote:
[..]
Ik zou dit soort taken niet bij de database server neerleggen. Queries moet je zo licht mogelijk schrijven, zodat je de database server zo min mogelijk lastig valt.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ik denk eigenlijk dat de database een stuk efficiënter z'n eigen data kan manipuleren dan de applicatie die deze data verder verwerkt.quote:
[..]
Het is niet fout, maar kwa belasting wil je het gewoon niet.
quote:
[..]
Ik denk eigenlijk dat de database een stuk efficiënter z'n eigen data kan manipuleren dan de applicatie die deze data verder verwerkt.
Indeed.quote:
[..]
Als je round door je db-clients wilt laten uitrekenen, ben je verkeerd bezig.
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Ja, dat is wel waar. Maar het hangt compleet van de situatie af of je dergelijke dingen laat berekenen door de DBengine of door de applicatie zelf. Als het puur en alleen om weergave gaat zou ik zeggen dat het door de applicatie gedaan moet worden. Als het om tussentabellen gaat of iets in die geest dan kan ik me nog voorstellen dat je het de DBengine laat doen.quote:
[..]
Ik denk eigenlijk dat de database een stuk efficiënter z'n eigen data kan manipuleren dan de applicatie die deze data verder verwerkt.
Nee?quote:
[..]
Das knap, het eens zijn met twee quotes die elkaar tegenspreken.
Het is rekenkracht wat je kwijt bent, bij 10 request per minuut maakt het geen fuck uit, maar als je request omhoog gaan dan wil je niet dat je DB server met dit soort dingen bezig is.quote:
Dat probeer ik hier te zeggen.quote:
[..]
Als je round door je db-clients wilt laten uitrekenen, ben je verkeerd bezig.
ja, want deze eerste zegt. Leg het neer bij de DB en de andere zegt doe het niet want dan ben je verkeerd bezig.quote:
Op
Je begrijpt het verschil tussen server en client?quote:
[..]
ja, want deze eerste zegt. Leg het neer bij de DB en de andere zegt doe het niet want dan ben je verkeerd bezig.
Dat is niet altijd een criterium omdat je vaak eenvoudig servers waar de applicatie op draaien kunt bijplaatsen.quote:
[..]
Ik denk eigenlijk dat de database een stuk efficiënter z'n eigen data kan manipuleren dan de applicatie die deze data verder verwerkt.
Geef me maar root-toegang op een server die 50.000 queries per seconde afhandelt, zal ik je 10 dingen aanwijzen die elk een miljoen keer meer opleveren.quote:
[..]
Het is rekenkracht wat je kwijt bent, bij 10 request per minuut maakt het geen fuck uit, maar als je request omhoog gaan dan wil je niet dat je DB server met dit soort dingen bezig is.
Niet waar, jij wilt het van je db-server naar je db-client verplaatsen.quote:Dat probeer ik hier te zeggen.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ah, dan las ik het verkeerd. Ik denk trouwens wel dat er geen gouden regel is voor deze problematiek.
Dat denk ik ook. Het is ook duidelijk dat je moet proberen een trage query te voorkomen natuurlijk. Maar dat doe je niet door de round-functie van je database te vermijden.quote:
Ah, dan las ik het verkeerd. Ik denk trouwens wel dat er geen gouden regel is voor deze problematiek.
Ik weet niet wat jij bedoelt met DB-server en DB-client.quote:Op dinsdag 10 januari 2012 11:08 schreef Tijn het volgende:
[..]
Je begrijpt het verschil tussen server en client?
Maar ik heb even een test uitgevoerd. 100 x een query opgehaald waar 2x50 float in voorkomen. In de ene heb ik hem door PHP laten afronden en in de andere heb ik het door MySQL laten doen. En het verschil is dat PHP er 35% langer over doet wanneer deze zelf de getallen nog moet afronden.
Dan had Tijn het dus toch goed dat de DB-server zelf efficiënter zijn data kan manipuleren.
Nouja, daar zat ik er dus naast ik dacht altijd dat je zulke functie niet daar moest uitvoeren. Vraag ik mij nu alleen af of dit ook geldt voor berekeningen.
Straks maar eens doen 
eerst koffie!
Kom op, een DB-server en een DB-client zijn twee hele normale, gangbare begrippen.
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
De machine waar de database zelf op staat is de databaseserver. De machine waar de applicatie op draait die met de database verbinding heeft is de databaseclient.quote:
[..]
Ik weet niet wat jij bedoelt met DB-server en DB-client.
100x zegt niks. Doe hem eens 100.000 keer.quote:
[..]
Ik weet niet wat jij bedoelt met DB-server en DB-client.
Maar ik heb even een test uitgevoerd. 100 x een query opgehaald waar 2x50 float in voorkomen. In de ene heb ik hem door PHP laten afronden en in de andere heb ik het door MySQL laten doen. En het verschil is dat PHP er 35% langer over doet wanneer deze zelf de getallen nog moet afronden.
Dan had Tijn het dus toch goed dat de DB-server zelf efficiënter zijn data kan manipuleren.
Nouja, daar zat ik er dus naast ik dacht altijd dat je zulke functie niet daar moest uitvoeren. Vraag ik mij nu alleen af of dit ook geldt voor berekeningen.
Op dinsdag 13 augustus schreef Xa1pt:
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
Neuh, fraude mag best aangepakt worden. Maar dat het de maatschappij meer oplevert of beter is voor de samenleving, is nog maar de vraag.
Op donderdag 25 juni 2015 schreef KoosVogels:
Klopt. Ik ben een racist.
