[naak2803]

Ursprungligen postat av Nerix

En dålig och ickeskalbar lösning som dessutom introducerar ett nytt problem; cache invalidation. Databasen är designad för att snabbt lösa just sådana här problem.

Enklast är om TS bara postar hela sin query. Hen gör förmodligen någon märklig JOIN vilket ställer till problem.

SELECT * FROM tp_question INNER JOIN tp_exam_tp_question ON tp_question.Id=tp_exam_tp_question.tp_questionsId WHERE tp_examId = 445 ORDER BY RAND() LIMIT 50

[Nerix]

Ursprungligen postat av naak2803

SELECT * FROM tp_question INNER JOIN tp_exam_tp_question ON tp_question.Id=tp_exam_tp_question.tp_questionsId WHERE tp_examId = 445 ORDER BY RAND() LIMIT 50

Nu vet jag inte exakt hur dina nycklar och data ser ut, så kan bara gissa. Me när du joinar med `tp_exam_tp_question` så dyker `tp_question.Id` förmodligen upp ett flertal gånger. Du väljer sedan slumpmässigt från frågor (tp_question.Id) som finns med fler gånger än andra i tabellen.

Vi kan verifiera min teori genom att du postar resultatet från följande query.

SELECT tp_question.Id FROM tp_question INNER JOIN tp_exam_tp_question ON tp_question.Id=tp_exam_tp_question.tp_questionsId WHERE tp_examId = 445 ORDER BY tp_question.Id ASC LIMIT 50

Se till att välja ett `tp_examId` så att du får med så många resultat som möjligt så att vi kan se att duplikat följer med.

Notera att en GROUP BY inte är lösning på din problem.

[tec]

Ursprungligen postat av naak2803

Hej,
jag har en quiz-motor med över 1000 frågor.
Men jag tycker inte att SQL-satsen fungerar dåligt och med dåligt menar jag att den inte slumpar tillräckligt slumpmässigt... Har ni några andra förslag?

SELECT * FROM dbo.quiz WHERE category = 445 LIMIT 20 ORDER BY RND()

Krav som jag har:
- Slumpa random
– Samma rad ska inte dyka upp flera ggr i samma fråga.

Så pass lite data att du lika gärna kan plocka ut alla rader och kasta om dem utanför Mysql. RAND() är otroligt slö.

<?php
$data = mysql_fetch_object("SELECT * FROM dbo.quiz WHERE category = 445");
shuffle($data);
$results = array_slice($data, 0, 20);

[Nerix]

Ursprungligen postat av tec

Så pass lite data att du lika gärna kan plocka ut alla rader och kasta om dem utanför Mysql. RAND() är otroligt slö.

<?php
$data = mysql_fetch_object("SELECT * FROM dbo.quiz WHERE category = 445");
shuffle($data);
$results = array_slice($data, 0, 20);

Din lösning är per definition ännu slöare. RAND() räkna alla element innan några väljs ut vilket tar O(n) tid. Din lösning kräver också O(n) läsningar + tiden det tar att hämta och skicka informationen mellan server och klient + bearbetning av datan.

[coredev]

Ursprungligen postat av Nerix

En dålig och ickeskalbar lösning som dessutom introducerar ett nytt problem; cache invalidation. Databasen är designad för att snabbt lösa just sådana här problem.

Jag förstår din poäng, men alla lösningar behöver inte vara skalbara. Hur många frågor kan OP förväntas ha?

Min arkitekturella utgångspunkt är att databasen skall göra så lite som möjligt - bättre att den gör det den är bra på och så låter man applikationslagret sköta resten. Enligt mig är OPs fall ett gränsfall, kanske är MySQL:s RAND-funktion bra nog för just detta fallet men i det stora hela är RAND inte designad för att skapa slumpmässiga tal av hög kvalité: "RAND() is not meant to be a perfect random generator. It is a fast way to generate random numbers on demand that is portable between platforms for the same MySQL version."

[Clarence]

För att illustrera lite hur pass dåliga de dåliga lösningarna faktiskt är. Kört med 7 miljoner ca 100-150 byte rader i en InnoDB tabell på en medelmåttig hårdvara, med en kraftig maskin kan man förvänta sig 20-50% av exekveringstiden:

Exekveringstid ca 15s.

SELECT * FROM table ORDER BY RAND() LIMIT 1

Exekveringstid ca 15s. Detta ger inga random-rader men används i vissa, riktigt dåliga, alternativ till ORDER BY RAND().

SELECT count(*) FROM table

Exekveringstid 0.02s. Kräver primary key (behöver inte heta id). Ger sämre resultat med större gaps i PK. Måste köras en gång per rad för hyfsad randomness (även om det givetvis går att kombinera i en query). Kan ge kopior varpå man måste ha kod för att hämta fler frågor om man får kopior. För många rader kan det effektiviseras ordentligt genom att lyfta ut id-generation (antingen i en stored procedure eller i kod).

SELECT *
FROM table
WHERE id >= FLOOR(1 + RAND() * (SELECT MAX(id) FROM table))
LIMIT 1

Detta är inte de enda alternativen utan bara en illustration till hur enorm skillnad det gör. Problemet med att använda ORDER BY RAND() ligger inte i hur pass exakt RAND() är utan hur pass fruktansvärd prestandan är vid ORDER BY RAND() på något annat än ett VÄLDIGT litet resultset.

[tec]

Ursprungligen postat av Nerix

Din lösning är per definition ännu slöare. RAND() räkna alla element innan några väljs ut vilket tar O(n) tid. Din lösning kräver också O(n) läsningar + tiden det tar att hämta och skicka informationen mellan server och klient + bearbetning av datan.

Körs totalt på 0.01s, 1000 rader motsvarande quizfrågor. Undviker att använda RAND(), som i sig är slö och som TS hade problem med.

[linusoleander]

Ursprungligen postat av tec

Körs totalt på 0.01s, 1000 rader motsvarande quizfrågor. Undviker att använda RAND(), som i sig är slö och som TS hade problem med.

Värt å tillägga är att din lösning inte löser problemet då de verkar som att TS query returnerar dubletter. De är således inget fel på RAND() utan queryn i sig.