Random rows uit database

[raymond88]

Nou, ik heb een tabel in de database, met zeg 500 records. Ik wil hieruit enkel 3 hiervan hebben, en dan ook nog eens random. Nou weet ik dat ik limit moet gebruiken, voor enkel 3 records, maar het random selecteren wil niet echt. Ik heb vanalles zitten lezen, en nou blijkt ORDER BY rand() niet echt heel vriendelijk (lees: snel) te zijn. Weet iemand een goede (lees: snellere) manier om dit keurig op te lossen?

Wat ik zelf al gelezen heb is een of ander veld aanmaken, met een uniqueidentifier, en daarop sorteren of iets dergelijks. Ik wou echter niet al te moeilijk gaan doen. Hoor het graag van jullie!

 

[kenikavanbis]

Nou, ik heb een tabel in de database, met zeg 500 records. Ik wil hieruit enkel 3 hiervan hebben, en dan ook nog eens random. Nou weet ik dat ik limit moet gebruiken, voor enkel 3 records, maar het random selecteren wil niet echt. Ik heb vanalles zitten lezen, en nou blijkt ORDER BY rand() niet echt heel vriendelijk (lees: snel) te zijn. Weet iemand een goede (lees: snellere) manier om dit keurig op te lossen?

Wat ik zelf al gelezen heb is een of ander veld aanmaken, met een uniqueidentifier, en daarop sorteren of iets dergelijks. Ik wou echter niet al te moeilijk gaan doen. Hoor het graag van jullie!

sorry als het zeer pretent lijkt maar alles in een file plaatsen
drie getallen in een array plaatsen en één lijn printen
dus crownjob voor het maken van de file met htmltags en een printer
elke database structuur is gewoon traag of nooit garrantie van snelheid Wordt enkel gebruikt voor het gemak en vele functies.Of je bent admin en je stop onmiddelijk min 3gig in of naargelang gebruik maar bekijk dan eerst kvm=>

 

[Frats]

Als het gaat over "performance" en "databases" dan moet je denken aan 100.000+ rijen.

Voor 500 rijen is ORDER BY RAND() uitstekend geschikt, maar je daar maar niet druk om.

Wat je nog kunt overwegen ALS en ALLEEN ALS je nooit rijen verwijderd (zodat de ids aansluitend blijven) is om de getallen met de RAND() functie in PHP te genereren (van tevoren even de hoogste id ophalen) maar dat gaat natuurlijk niet werken als er getallen ontbreken.

Maar als het aantal rijen niet boven de 50.000 ofzo uitkomt zou ik je nog geen zorgen maken.

 

[kenikavanbis]

Ok maar stel shared hosting doet me denken aan 700 databases mogelijks pieken optreden waar de server veel door vertraagt das het verschil tussen goedkopen duurdere hosting.

Ok maar stel dat je zelf één heb de database server ook application server is en door zoek resultaten vertraagt By Mysql zie je 1tabel =1 bestand maar ooit kan het verbeteren

laten we denken veel gegevens 1.000.000 per 1000 één file dus hoef je enkel de files te sorteren en intern te sorteren en door de gesplite naam.1.ext =>naam.1000.ext zal je door je eigen programma sneller kunne zoeken door je gegevens maar het kan beter stel je weet welke gegevens je meest nodig hebt dus naam.A.1.ext , naam.A.2.ext =>naam.Y.1000.ext
maakt dus dat je ook weet welke beginletters er in de file bevinden dus hoef je deze niet nodeloos te doorzoeken. Referentie files gaan meestal naar de betreffende data verwijderen of gewoon de data bezitten dus database ja maar niet altijd de beste oplossing.

 

[raymond88]

OK, een beetje te hard geroepen door andere dus, dat RAND() traag is. Veelal zie je weinig beargumenteert wanneer men zoiets zegt, en weet ik dus niet wat te geloven.

Ik was een beetje bang dat al mijn transacties wat te lang zouden gaan duren, maar hierbij is mijn vraag dus opgelost. Bedankt. :thumb:

 

[Frats]

Ze hebben opzich een punt dat ORDER BY RAND() traag is. Het is alleen altijd heel belangrijk om te kijken op welke schaal het artikel geschreven is, en of wat jij doet binnen die schaal valt

De meeste hobbyprojecten zijn zo klein en de meeste hardware zo krachtig dat "traag" gewoon niet voorkomt.
Dus het beste kun je het gewoon proberen en dan even benchmarken hoe lang het duurt, dan kom je er vaak achter dat het heel erg meevalt.

@kenikavanbis: ik kan geen touw aan je verhaal vastknopen maar volgensmij is wat jij voorstelt geen handig idee.

 

[raymond88]

Ze hebben opzich een punt dat ORDER BY RAND() traag is. Het is alleen altijd heel belangrijk om te kijken op welke schaal het artikel geschreven is, en of wat jij doet binnen die schaal valt

De meeste hobbyprojecten zijn zo klein en de meeste hardware zo krachtig dat "traag" gewoon niet voorkomt.
Dus het beste kun je het gewoon proberen en dan even benchmarken hoe lang het duurt, dan kom je er vaak achter dat het heel erg meevalt.

@kenikavanbis: ik kan geen touw aan je verhaal vastknopen maar volgensmij is wat jij voorstelt geen handig idee.

Yes, duidelijk. Het is dan niet echt een hobbyproject, maar meer dan 500 (in het 'slechtse' geval denk ik 1500) results zal 'ie niet door hoeven te gaan.

 

[SvU]

Als het gaat over "performance" en "databases" dan moet je denken aan 100.000+ rijen.

Dan onderschat je nog steeds de kracht van een database hoor. 100.000 is nog steeds helemaal niks, als je er vanuit gaat dat je geen idioot grote rows hebt. Als je database met miljoenen records langzaam wordt, moet je optimaliseren of meer kracht achter de databaseserver zetten.

Dat dan wel weer even los van RAND(), iets dat je in de praktijk eigenlijk nooit op een grote tabel gebruikt. (Net op een tabel geprobeerd met 100.000 rows, kostte 4 seconden. Behoorlijk traag inderdaad.)