[MySQL] Hoe voorkom ik video tussen relaterend video's

[IkBenErOokWeer]

Ik ben een videosite aan het maken waar op de video pagina relateerde video's staan.
Nu gebruik ik de volgende query:

MySQL:

SELECT * FROM Vids Tags LIKE 'huppelepup' ORDER BY rand() LIMIT 8

En mijn probleem is dat soms de video die ze bekijken ook voorkomt in de gerelateerde video's
Hoe kan ik deze eruit halen?
Bijvoorbeeld video met VidID 1234 die niet terug mag komen in de gerelateerde video's?

[Wiethoofd]

Een WHERE != $huidigID toevoegen in je query? of denk ik nu te makkelijk...

[ Voor 25% gewijzigd door Wiethoofd op 17-11-2011 15:05 ]

[hellfighter87]

zoals hierboven al gezecht o_O * had niet goed gelezen ;'( *

[ Voor 76% gewijzigd door hellfighter87 op 17-11-2011 15:10 ]

[Hydra]

Wiethoofd schreef op donderdag 17 november 2011 @ 15:05:
Een WHERE != $huidigID toevoegen in je query? of denk ik nu te makkelijk...

Lijkt mij ook.

En "order by rand()", yuck!

hellfighter87 schreef op donderdag 17 november 2011 @ 15:07:
where vidoeId not in (select videoId from gerelateerdevideos)

Je slaat de plank aardig mis.

[ Voor 31% gewijzigd door Hydra op 17-11-2011 15:09 ]

[GlowMouse]

http://www.electrictoolbo...lternative-order-by-rand/

[IkBenErOokWeer]

Wiethoofd schreef op donderdag 17 november 2011 @ 15:05:
Een WHERE != $huidigID toevoegen in je query? of denk ik nu te makkelijk...

Dank u! Dit blijkt idd te werken:

MySQL:

SELECT * FROM Vids Tags LIKE 'huppelepup' WHERE VidID != 1234 ORDER BY rand() LIMIT 8

Hydra schreef op donderdag 17 november 2011 @ 15:09:
En "order by rand()", yuck!

GlowMouse schreef op donderdag 17 november 2011 @ 15:09:
http://www.electrictoolbo...lternative-order-by-rand/

Ik heb MySQL mijzelf een beetje aangeleerd, dus dit wist ik niet.
Gebruik RAND() eigenlijk best vaak in mijn scripts dus ga hier toch even verder naar kijken.
Dank u beide!

[T-MOB]

GlowMouse schreef op donderdag 17 november 2011 @ 15:09:
http://www.electrictoolbo...lternative-order-by-rand/

Dat is leuk als je 1 random item wil hebben. Niet als je 8 random items in random volgorde wil hebben.

[ Voor 98% gewijzigd door T-MOB op 17-11-2011 15:43 ]

[Hydra]

T-MOB schreef op donderdag 17 november 2011 @ 15:29:
Dat is leuk als je 1 random item wil hebben. Niet als je 8 random items in random volgorde wil hebben.

Nee, je kunt met die opzet ook meerdere resultaten selecteren. Alleen zijn die 8 dan zelf niet random. Maar dat kun je daarna zelf makkelijk oplossen. Daarnaast vind ik het logischer om dergelijke resultaten te sorteren op een userwaardering ofzo.

Je wil hoe dan ook niet dat er voor elke regel in de resultset een random nummer moet worden berekend. Da's leuk als het er 10 zijn, maar bij 10000 is dat gewoon een enorme performancehit.

[ Voor 36% gewijzigd door Hydra op 17-11-2011 15:39 ]

[Keiichi]

GlowMouse schreef op donderdag 17 november 2011 @ 15:09:
http://www.electrictoolbo...lternative-order-by-rand/

Is het met die methode niet zo als je 1 onbrekend id hebt dat het eigenlijk al niet meer goed werkt?

[T-MOB]

Hydra schreef op donderdag 17 november 2011 @ 15:38:
[...]
Nee, je kunt met die opzet ook meerdere resultaten selecteren. Alleen zijn die 8 dan zelf niet random. Maar dat kun je daarna zelf makkelijk oplossen. Daarnaast vind ik het logischer om dergelijke resultaten te sorteren op een userwaardering ofzo.

Mja, dan is het niet meer random. Het is goed om na te denken over hoe belangrijk random is en het waar mogelijk te vermijden. Wat dat betreft ben ik het wel met je eens dat een andere sortering handiger is.

Je wil hoe dan ook niet dat er voor elke regel in de resultset een random nummer moet worden berekend. Da's leuk als het er 10 zijn, maar bij 10000 is dat gewoon een enorme performancehit.

Maar om iemand die moeite heeft om een eenvoudige WHERE-conditie te bedenken onzeker te maken over het gebruik van RAND() lijkt me een beetje overdreven. Natuurlijk is het niet efficient om meer dan 8 random getallen te genereren als je maar 8 items nodig hebt, maar who cares? Als de tabel van de TS groeit krijgt hij waarschijnlijk eerder problemen met het niet genormaliseerd opslaan van tags en het ongeindexeerd zoeken in die tags... Maar ook dat geeft niet, sommige dingen leer je door er een keer tegenaan te lopen.

[ Voor 3% gewijzigd door T-MOB op 17-11-2011 15:51 ]

[GlowMouse]

Keiichi schreef op donderdag 17 november 2011 @ 15:41:
[...]


Is het met die methode niet zo als je 1 onbrekend id hebt dat het eigenlijk al niet meer goed werkt?

Jazeker, maar als je er dan 5 nodig hebt dan vraag je er gewoon 10 op.

[NMe]

Laten we vooral niet roepen dat ORDER BY RAND() per definitie fout is trouwens. Voor relatief kleine resultsets is het een prima oplossing.

[GlowMouse]

NMe schreef op donderdag 17 november 2011 @ 18:54:
Laten we vooral niet roepen dat ORDER BY RAND() per definitie fout is trouwens. Voor relatief kleine resultsets is het een prima oplossing.

Het hangt wel van meer factoren af. We hebben het over MySQL, dus er hoeft maar één text kolom in je resultset te zitten of de sortering vindt op de harddisk plaats. Dan kun je nog zo'n kleine resultset hebben, het kost je je disk io.

[Gomez12]

GlowMouse schreef op donderdag 17 november 2011 @ 18:59:
[...]

Het hangt wel van meer factoren af. We hebben het over MySQL, dus er hoeft maar één text kolom in je resultset te zitten of de sortering vindt op de harddisk plaats. Dan kun je nog zo'n kleine resultset hebben, het kost je je disk io.

Tussendoorvraagje, zou het dan efficienter zijn om het dan in 2 query's te splitsen door eerst enkel x random prinary keys op te halen (compleet in memory hoop ik) om daarna de resultset op te halen adhv die random id's?

[GlowMouse]

Gomez12 schreef op donderdag 17 november 2011 @ 19:18:
[...]

Tussendoorvraagje, zou het dan efficienter zijn om het dan in 2 query's te splitsen door eerst enkel x random prinary keys op te halen (compleet in memory hoop ik) om daarna de resultset op te halen adhv die random id's?

Dat kan inderdaad sneller zijn.

[Avalaxy]

Wat is 'vids tags' voor tabel eigenlijk? Dat daar een spatie in zit vind ik heel erg raar (en raad ik absoluut heel erg af). Ik vermoed dat het een soort koppeltabel is, maar waarom zit daar dan de waarde van je tag in? Een tag heeft normaal toch meerdere filmpjes en een filmpje meerdere tags, dan heb je toch een koppeltabel met alleen 2 referenties erin?

Wat ik persoonlijk zou doen is gewoon door de filmpjes lopen en kijken welke filmpjes overlappende tags hebben, en de filmpjes met de meeste overlappingen tonen.

[NMe]

Avalaxy schreef op donderdag 17 november 2011 @ 19:27:
Wat is 'vids tags' voor tabel eigenlijk? Dat daar een spatie in zit vind ik heel erg raar (en raad ik absoluut heel erg af).

In de syntax zoals die in de startpost staat wordt het een impliciete alias, toch? Vids wordt dan aanspreekbaar met Tags. Het zou `Vids Tags` zijn als de tabelnaam een spatie zou bevatten.

[T-MOB]

De syntax uit de startpost levert een query error op. Volgens mij is de echte query niet goed overgetypt en is het eigenlijk:

SQL:

SELECT * FROM Vids WHERE Tags LIKE 'huppelepup' ORDER BY rand() LIMIT 8

Dus met een WHERE tussen Vids en Tags.
Ik vermoed verder dat alle tags in het textveld Tags gepropt zijn (waarom zou je ander LIKE gebruiken ipv "="). En vandaar dat ik denk dat alternatieven voor ORDER BY RAND() een beetje prematuur zijn. Tot zover de glazen bol

[Keiichi]

Ik heb voor de gein eens een dergelijke query op een 'kleine' database bestaande uit 1.6 miljoen rijen gedaan. (de rijen zijn ook lang, 1kilobyte gemiddeld)

Resultaat: 1 row in set (1 min 30.16 sec)

[Gomez12]

T-MOB schreef op donderdag 17 november 2011 @ 20:30:
De syntax uit de startpost levert een query error op. Volgens mij is de echte query niet goed overgetypt en is het eigenlijk:

SQL:

SELECT * FROM Vids WHERE Tags LIKE 'huppelepup' ORDER BY rand() LIMIT 8

Dus met een WHERE tussen Vids en Tags.
Ik vermoed verder dat alle tags in het textveld Tags gepropt zijn (waarom zou je ander LIKE gebruiken ipv "="). En vandaar dat ik denk dat alternatieven voor ORDER BY RAND() een beetje prematuur zijn. Tot zover de glazen bol

like zonder wildcards is afaik toch equivalent aan where?

Misschien niet db-intern, maar vanaf de gebruikers kant is het toch gelijk?

[Voutloos]

GlowMouse schreef op donderdag 17 november 2011 @ 18:59:
[...]

Het hangt wel van meer factoren af. We hebben het over MySQL, dus er hoeft maar één text kolom in je resultset te zitten of de sortering vindt op de harddisk plaats. Dan kun je nog zo'n kleine resultset hebben, het kost je je disk io.

Nope. EXPLAIN zal inderdaad 'filesort' aangeven, maar dit vindt, ondanks dat de naam anders doet vermoeden, gewoon plaats in het geheugen zolang < sort_buffer_size .
http://dev.mysql.com/doc/...rder-by-optimization.html

Maar dit soort trivia, en uberhaupt de hele ORDER BY RAND() discussie (wat inderdaad al snel hoerig traag wordt) is nog niet weggelegd voor de ts, aangezien deze eerst WHERE onder de knie moet krijgen.

[ Voor 14% gewijzigd door Voutloos op 17-11-2011 23:36 ]

[NMe]

Gomez12 schreef op donderdag 17 november 2011 @ 23:12:
[...]

like zonder wildcards is afaik toch equivalent aan where?

Ik neem aan dat je "equivalent aan =" bedoelt.

[Gomez12]

NMe schreef op donderdag 17 november 2011 @ 23:38:
[...]

Ik neem aan dat je "equivalent aan =" bedoelt.

Zei ik toch als je een beetje krom kijkt

Maar dat klopt toch wat ik zeg of zit er wel een gebruikers verschil in ( ik kan me zo voorstellen dat bij sommige dbase implementaties er verschillen zitten of er wel / geen indexen gebruikt worden etc maar daar heb ik het even niet over)

[ Voor 36% gewijzigd door Gomez12 op 18-11-2011 00:44 ]

[RobIII]

Gomez12 schreef op vrijdag 18 november 2011 @ 00:43:
Maar dat klopt toch wat ik zeg of zit er wel een gebruikers verschil in

Nee, zonder wildcard zit er geen verschil in de output ("gebruikersverschil"). Sterker: ik mag hopen dat de gemiddelde query-planner (query optimizer technically) in een RDBMS dit wegoptimaliseert naar een "=".

_{Een edge-case zou een parameterized query / stored procedure zijn waar het executionplan eenmalig bepaald wordt en daarna hergebruikt; wanneer de parameter op voorhand onbekend is (ie. bevat 'ie een wildcard of niet) dan moet natuurlijk het "dure" executionplan aangenomen worden.}

Natuurlijk geldt, zoals altijd, dat je beter gewoon expliciet zegt wat je bedoelt want er is altijd nog een Murphy's Law.

[ Voor 63% gewijzigd door RobIII op 18-11-2011 01:09 ]

[ReenL]

Keiichi schreef op donderdag 17 november 2011 @ 15:41:
[...]


Is het met die methode niet zo als je 1 onbrekend id hebt dat het eigenlijk al niet meer goed werkt?

Nee, hij berekent namelijk de totale grootte van de tabel, en doet een LIMIT ?, 1, het zegt niet, WHERE id = ?.