Kom ihåg mig?

Mysql random verkar inte vara tillräckligt bra?

 
Ämnesverktyg Visningsalternativ
Oläst 2015-09-11, 10:47 #1
coredevs avatar
coredev coredev är inte uppkopplad
Bara ett inlägg till!
 
Reg.datum: Sep 2007
Inlägg: 1 554
coredev coredev är inte uppkopplad
Bara ett inlägg till!
coredevs avatar
 
Reg.datum: Sep 2007
Inlägg: 1 554
Citat:
Ursprungligen postat av naak2803 Visa inlägg
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?

Kod:
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.
Som flera andra redan har varit inne på, gör på följande sätt:
1) Hämta unika fråge-id:n från databasen:
Kod:
SELECT id FROM dbo.quiz WHERE category = 445
2) Slumpa och begränsa dessa i ditt applikationslager (php, asp, jsp, etc).

3) Hämta sedan frågorna via ytterligare en SQL:
Kod:
SELECT column1, column2, etc... FROM dbo.quiz WHERE id in (1, 7, 32, 94, etc...)
Du får visseligen en ytterligare fråga till databasen men resultatet från den kan du enkelt cacha i ditt applikationslager.
coredev är inte uppkopplad   Svara med citatSvara med citat
Oläst 2015-09-12, 00:39 #2
Nerix Nerix är inte uppkopplad
Flitig postare
 
Reg.datum: Oct 2010
Inlägg: 398
Nerix Nerix är inte uppkopplad
Flitig postare
 
Reg.datum: Oct 2010
Inlägg: 398
Citat:
Ursprungligen postat av coredev Visa inlägg
Som flera andra redan har varit inne på, gör på följande sätt:
1) Hämta unika fråge-id:n från databasen:
Kod:
SELECT id FROM dbo.quiz WHERE category = 445
2) Slumpa och begränsa dessa i ditt applikationslager (php, asp, jsp, etc).

3) Hämta sedan frågorna via ytterligare en SQL:
Kod:
SELECT column1, column2, etc... FROM dbo.quiz WHERE id in (1, 7, 32, 94, etc...)
Du får visseligen en ytterligare fråga till databasen men resultatet från den kan du enkelt cacha i ditt applikationslager.
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.
Nerix är inte uppkopplad   Svara med citatSvara med citat
Oläst 2015-09-12, 13:47 #3
naak2803 naak2803 är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Jun 2011
Inlägg: 767
naak2803 naak2803 är inte uppkopplad
Mycket flitig postare
 
Reg.datum: Jun 2011
Inlägg: 767
Citat:
Ursprungligen postat av Nerix Visa inlägg
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
naak2803 är inte uppkopplad   Svara med citatSvara med citat
Oläst 2015-09-12, 13:56 #4
Nerix Nerix är inte uppkopplad
Flitig postare
 
Reg.datum: Oct 2010
Inlägg: 398
Nerix Nerix är inte uppkopplad
Flitig postare
 
Reg.datum: Oct 2010
Inlägg: 398
Citat:
Ursprungligen postat av naak2803 Visa inlägg
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.

Kod:
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.
Nerix är inte uppkopplad   Svara med citatSvara med citat
Oläst 2015-09-14, 09:09 #5
coredevs avatar
coredev coredev är inte uppkopplad
Bara ett inlägg till!
 
Reg.datum: Sep 2007
Inlägg: 1 554
coredev coredev är inte uppkopplad
Bara ett inlägg till!
coredevs avatar
 
Reg.datum: Sep 2007
Inlägg: 1 554
Citat:
Ursprungligen postat av Nerix Visa inlägg
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."
coredev är inte uppkopplad   Svara med citatSvara med citat
Svara


Aktiva användare som för närvarande tittar på det här ämnet: 1 (0 medlemmar och 1 gäster)
 
Ämnesverktyg
Visningsalternativ

Regler för att posta
Du får inte posta nya ämnen
Du får inte posta svar
Du får inte posta bifogade filer
Du får inte redigera dina inlägg

BB-kod är
Smilies är
[IMG]-kod är
HTML-kod är av

Forumhopp


Alla tider är GMT +2. Klockan är nu 06:54.

Programvara från: vBulletin® Version 3.8.2
Copyright ©2000 - 2026, Jelsoft Enterprises Ltd.
Svensk översättning av: Anders Pettersson
 
Copyright © 2017