Är det så att man alltid riskerar att rand() ger dubletter (eller ännu fler visningar av samma post) om man väljer order by rand() och kan det bli så att vissa poster inte alls visas på bekostnad av andra posters dubletter???
Pröva att köra SELECT DISTINCT Jag är inte säker på syntaxen. Antingen kanske det går med SELECT DISTINCT * FROM... eller så kanske du måste ange ett fält SELECT DISTINCT id, message, ... FROM...
Rand() påverkar inte urvalet, utan endast sorteringen. Så om du ser till att din SQL-fråga endast ger unika svar så bör ju sorteringen fungera.
Om frågan inte gäller poster i samma resultatset så ja, det kan absolut bli så att vissa poster slumpas fram oftare än andra. Jag gjorde ett litet test för ett tag sedan (visserligen med Microsoft SQL Server) bara för att se hur stor risken är, och i en datamängd på c:a 30000 poster, och c:a 100000 slumpningar, så hade vissa poster blivit framslumpade 20 gånger, och ett tusental inte alls.
Hej!
Tack för era svar!
Jag använder mig redan av select distinct och sql frågan utan rand() ger endast unika poster. Sql frågan är dock rätt komplex med flera "join" och flera villkor som ska uppfyllas.
Mvh Lena
En annan detalj; om jag tar bort order by rand() och istället väljer en annan order by så blir det alltså bara unika poster. Men det sammanlagda antalet poster är exakt samma som vid order by rand() med dubletter. Alltså måste ju en del poster inte visas alls.
Hej igen!
Har dragit slutsatsen att det måste ha med funktionen för sidnavigering att göra. Samma poster visas nämligen aldrig på samma sida även om jag ändrar och t.ex. sätter att jag vill visa 100 poster per sida.
Exakt vad det är som orsaker felet vet jag inte. Men det är ju underligt att det fungerar med alla andra sorteringsalternativ (order by) utom just rand().
Om du ställer en SQL-fråga med rand()-sortering två gånger så får du ju två olika sorteringsordningar. Det är inget konstigt med det.
Vill du ha slumpvis sortering och paging så får du se till att du bara ställer frågan en enda gång, och se till att cachea resultatet på något sätt, temporär tabell, array i sessionsobjekt, etc.
130 ms totalt · 3 externa anrop · v20260731065814-full.4bcf49fe