[MySQL] Probleem met query voor een top 10

[Maghiel]

Ik heb een website met daarop een top 10 van meest beluisterde nummers.
Een album of single mag daar echter maar 1 keer in voorkomen: dit om te voorkomen
dat er bijvoorbeeld 3 tracks van eenzelfde album in de top10 voorkomen.
Dit is echter simpeler gezegd dan gedaan, en ik kom er dan ook echt niet uit.

Dit zijn de tabellen die relevant zijn:

code:

CREATE TABLE IF NOT EXISTS `main_statistics_listened` (
  `id` int(11) NOT NULL auto_increment,
  `remote_ip` varchar(16) default NULL,
  `trackid` int(11) default NULL,
  `siteshopid` int(11) default NULL,
  `timestamp` int(11) default NULL,
  PRIMARY KEY  (`id`),
  KEY `remote_ip` (`remote_ip`),
  KEY `trackid` (`trackid`),
  KEY `siteshopid` (`siteshopid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;


CREATE TABLE IF NOT EXISTS `main_tracks` (
  `id` int(11) NOT NULL auto_increment,
  `artistid` int(11) default NULL,
  `albumnumber` int(11) default NULL,
  `name` varchar(250) default NULL,
  `previewtime` int(11) default NULL,
  `fullpreview` enum('0','1') NOT NULL,
  `artist1` varchar(250) NOT NULL default '',
  `artist2` varchar(250) NOT NULL default '',
  `composer` varchar(250) default NULL,
  `lyricist` varchar(250) default NULL,
  `isrc` varchar(250) default NULL,
  `promobomb` enum('1','0') default '0',
  `priceid` int(11) NOT NULL default '0',
  `key` varchar(250) NOT NULL default '0',
  `filesize` int(11) NOT NULL default '0',
  `seconds` float NOT NULL default '0',
  `type` enum('album','single') NOT NULL default 'album',
  `typeid` int(11) NOT NULL default '0',
  PRIMARY KEY  (`id`),
  KEY `typeid` (`typeid`),
  KEY `priceid` (`priceid`),
  KEY `artistid` (`artistid`),
  KEY `type` (`type`),
  KEY `albumnumber` (`albumnumber`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `main_albums` (
  `id` int(11) NOT NULL auto_increment,
  `artistid` int(11) default NULL,
  `title` varchar(250) default NULL,
  `year` int(11) default NULL,
  `ean` varchar(250) default NULL,
  `rightsid` int(11) NOT NULL default '0',
  `salestartdate` date default NULL,
  `frontcover` varchar(250) default NULL,
  `fullpriceid` int(11) default NULL,
  `onlyfull` enum('0','1') default '0',
  `visible` enum('0','1') default '0',
  `adddate` date NOT NULL default '0000-00-00',
  `isreleased` enum('0','1','2') NOT NULL default '0',
  `releasedate` datetime default NULL,
  PRIMARY KEY  (`id`),
  KEY `fullpriceid` (`fullpriceid`),
  KEY `artistid` (`artistid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

CREATE TABLE IF NOT EXISTS `main_singles` (
  `id` int(11) NOT NULL auto_increment,
  `artistid` int(11) NOT NULL default '0',
  `title` varchar(250) default NULL,
  `year` int(11) default NULL,
  `ean` varchar(250) default NULL,
  `rightsid` int(11) NOT NULL default '0',
  `salestartdate` date default NULL,
  `frontcover` varchar(250) default NULL,
  `visible` enum('0','1') default '0',
  `adddate` date NOT NULL default '0000-00-00',
  `isreleased` enum('0','1','2') NOT NULL default '0',
  `releasedate` datetime default NULL,
  PRIMARY KEY  (`id`),
  KEY `artistid` (`artistid`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1;

main_statistics_listened.trackid verwijst naar main_tracks.id
main_tracks.type verwijst naar main_albums ofwel main_singles
en main_tracks.typeid is dan main_albums.id of main_singles.id

dit is de query die ik nu heb:

code:

SELECT 
SQL_CALC_FOUND_ROWS DISTINCT `main_tracks`.`typeid`,
`trackid`, COUNT(`trackid`) AS `times_listened`, 
`main_tracks`.`name` AS `tracktitle`, `main_tracks`.`type`, 
CASE `main_tracks`.`type`
    WHEN 'single' THEN (SELECT `frontcover` FROM `main_singles` WHERE `id` = `main_tracks`.`typeid`)
    WHEN 'album' THEN (SELECT `frontcover` FROM `main_albums` WHERE `id` = `main_tracks`.`typeid`)
END AS `frontcover`,        
`main_artists`.`id` AS `artistid`, `main_artists`.`name` AS `artistname`, `main_artists`.`username`, `main_artists`.`labelusername`, `main_artists`.`genreid`,
CASE `main_artists`.`labelusername`
    WHEN '0' THEN '0'
    ELSE (SELECT `activated`  FROM `main_labels` WHERE `username` = `main_artists`.`labelusername`)
END AS `labelactivated`,    
`main_genres`.`title` AS `genre`,
`main_picture`.`picname` AS `artistimage`
FROM `main_statistics_listened`
INNER JOIN `main_tracks` ON `main_statistics_listened`.`trackid` = `main_tracks`.`id`
INNER JOIN `main_artists` ON `main_tracks`.`artistid` = `main_artists`.`id`
INNER JOIN `main_genres` ON `main_artists`.`genreid` = `main_genres`.`id`
LEFT JOIN `main_labels` ON `main_artists`.`labelusername` = `main_labels`.`username`
LEFT JOIN `main_picture` ON (`main_artists`.`id` = `main_picture`.`artist_id` AND `main_picture`.`user_type` = 'artist')
WHERE (`main_artists`.`activated` = '1' OR `main_labels`.`activated` = '1')
AND `siteshopid`= '0'
GROUP BY `main_tracks`.`typeid`
ORDER BY `times_listened` DESC LIMIT 0, 12

kan iemand mij alsjeblieeeeeft hiermee helpen ik zit hier nu al weken mijn kop op te breken maar kom er niet uit!

[Janoz]

Ik heb niet druk door al je creatie en query sql gekeken, maar als ik zo naar de gewenste gegevens kijk dan zou ik de volgende benadering nemen:

Eerst van elk album het meest beluisterde nummer nemen en dan deze allemaal gebruiken om je top 10 van te maken.

[daaan]

Als je nou eerst eens een query draait die alles optelt, ie:

code:

select trackid, count(trackid) as aantal from main_statistics_listened group by trackid order by aantal desc limit 10

En met deze resultset haal je dan per trackid gegevens op. je hebt dan wel 11 query's, maar geen universitaire studie mysql nodig.

* maar helaas zag ik de albums over het hoofd en is mijn query nutteloos

[ Voor 11% gewijzigd door daaan op 08-01-2008 13:28 ]

[Dido]

daaan schreef op dinsdag 08 januari 2008 @ 13:09:
En met deze resultset haal je dan per trackid gegevens op. je hebt dan wel 11 query's, maar geen universitaire studie mysql nodig.

En jij garandeert dan persoonlijk dat track 1 en track 2 niet op hetzelfde album staan?

edit: en waarom een disctinct bij een group by

De aanpak van Janoz lijkt me een redelijk trefzekere manier om dit aan te pakken

[ Voor 17% gewijzigd door Dido op 08-01-2008 13:17 ]

[Maghiel]

Janoz schreef op dinsdag 08 januari 2008 @ 12:59:
Ik heb niet druk door al je creatie en query sql gekeken, maar als ik zo naar de gewenste gegevens kijk dan zou ik de volgende benadering nemen:

Eerst van elk album het meest beluisterde nummer nemen en dan deze allemaal gebruiken om je top 10 van te maken.

geen optie, dan zou er door élk album heengelopen moeten worden, dat zijn er een stuk of 12.000, dan ook door alle singles heengelopen moeten worden, ......
dat gaat iets te langzaam worden allemaal
bovendien worden gewoon de meestbeluisterde tracks opgeslagen, alleen is dus het probleem dat ze van een uniek album af moeten komen.

[Maghiel]

Dido schreef op dinsdag 08 januari 2008 @ 13:16:
[...]

En jij garandeert dan persoonlijk dat track 1 en track 2 niet op hetzelfde album staan?

edit: en waarom een disctinct bij een group by

De aanpak van Janoz lijkt me een redelijk trefzekere manier om dit aan te pakken

idd ook geen optie, en 11 queries gaat denk ik nogal een grote impact op de performance hebben.

waarom kun je op dit forum trouwens niet meerdere quotes in 1 reply gooien?

[Dido]

Waarom zou een

SQL:

select album, max(geluisterd) from tracktable group by album

langzaam zijn?

Maghiel schreef op dinsdag 08 januari 2008 @ 13:19:
waarom kun je op dit forum trouwens niet meerdere quotes in 1 reply gooien?

Dat jij het niet kunt betekent niet dat het niet kan, hoor.

(Gewoon naar beneden scrollen, dan zie je de rest van de replies, en nog steeds een quote-knop

edit: ik zit even naar je tables te kijken, en ik zie niet veekl verschil tussen een album en een single.

Mag ik aannemen dat "albumnumber" kan slaan op album- of singelID? Zo nee, waar vind je dat id dan? Of kijk ik er straal overheen?

[ Voor 82% gewijzigd door Dido op 08-01-2008 13:24 ]

[Maghiel]

Dido schreef op dinsdag 08 januari 2008 @ 13:19:
Waarom zou een

SQL:

select album, max(geluisterd) from tracktable group by album

langzaam zijn?

[...]

Dat jij het niet kunt betekent niet dat het niet kan, hoor.

(Gewoon naar beneden scrollen, dan zie je de rest van de replies, en nog steeds een quote-knop

edit: ik zit even naar je tables te kijken, en ik zie niet veekl verschil tussen een album en een single.

Mag ik aannemen dat "albumnumber" kan slaan op album- of singelID? Zo nee, waar vind je dat id dan? Of kijk ik er straal overheen?

weer wat geleerd

zoals ik in me post zei:

main_statistics_listened.trackid verwijst naar main_tracks.id
main_tracks.type verwijst naar main_albums ofwel main_singles (type = 'single','album')
en main_tracks.typeid is dan main_albums.id of main_singles.id

albumnumber slaat op de positie van het nummer in het album, heeft hier verder dus niets mee te maken.

SQL:

select album, max(geluisterd) from tracktable group by album

kan niet, want de statistieken staan in main_statistics_listenened

[Janoz]

Maghiel schreef op dinsdag 08 januari 2008 @ 13:33:

SQL:

select album, max(geluisterd) from tracktable group by album

kan niet, want de statistieken staan in main_statistics_listenened

Er word een voorbeeld query gegeven waar je mee aan de slag kunt. Dat de statistieken in een andere tabel staat doet daar helemaal niks aan af en heb je er zo met een join bij.

Verder zou ik trouwens gewoon de single en de albums niet in aparte tabellen zetten. Zet deze gewoon in 1 tabel waarbij je eventueel een extra type veld opneemt

[ Voor 15% gewijzigd door Janoz op 08-01-2008 14:21 ]

[Maghiel]

Janoz schreef op dinsdag 08 januari 2008 @ 14:11:
[...]

Er word een voorbeeld query gegeven waar je mee aan de slag kunt. Dat de statistieken in een andere tabel staat doet daar helemaal niks aan af en heb je er zo met een join bij.

Verder zou ik trouwens gewoon de single en de albums niet in aparte tabellen zetten. Zet deze gewoon in 1 tabel waarbij je eventueel een extra type veld opneemt

ja maar op die manier moet ie dus álles aflopen, terwijl er van helemaal niet zoveel tracks luisterstatistieken zijn. het lijkt mij sneller om vanuit de statistieken te kijken, omdat je dan al gelijk weet welke tracks er het meest geluisterd zijn. alleen moeten dubbele albums/singles er dan wel uitgefilterd worden.

albums en singles in 1 tabel is geen optie meer, wat ik zei, er zijn een stuk of 12000 albums, en ongeveer 9000 singles. dat kan nu niet meer teruggedraaid worden. bovendien zijn er andere redenen waarom het gesplitst is, beetje teveel werk en irrelevant om hier uit te leggen.

[Verwijderd]

Alles kan teruggedraaid worden of in ieder geval opnieuw gevuld.

Heb zelf redelijk veel databases gemaakt; en kom je er halverwege (maar liever eerder) achter dat er iets niet klopt/veel problemen oplevert, dan verander je het ontwerp, en ga je niet om de problemen heen friemelen.

Dat neemt niet weg, dat ik van mening ben dat een top10 een top10 is. En dat zijn de 10 meest beluisterde nummers... Dat ze op hetzelfde album staan, zou in mijn optiek van geen belang zijn.

[Janoz]

Maghiel schreef op dinsdag 08 januari 2008 @ 14:26:
ja maar op die manier moet ie dus álles aflopen, terwijl er van helemaal niet zoveel tracks luisterstatistieken zijn. het lijkt mij sneller om vanuit de statistieken te kijken, omdat je dan al gelijk weet welke tracks er het meest geluisterd zijn. alleen moeten dubbele albums/singles er dan wel uitgefilterd worden.

Ja, maar dat wil je niet weten dus heb je er ook niet veel aan. Je zult het toch op een dergelijke manier moeten doen. Een andere oplossing is om niet 10, maar 10x het maximaal aantal tracks op een album/single op te vragen en dan vervolgens in je eigen code de dubbele albums eruit te filteren.

Verder maakt het geinsert hebben van duizenden records natuurlijk geen kont uit. Een conversiescript kun je gewoon laten draaien en daarvoor maakt het niet uit of het 100000 of 10 items zijn. Al geschreven code kun je blijvend laten werken door views te maken op die nieuwe tabel die op de oude tabellen lijken.

Het loont gewoon bijna altijd om je database model goed te hebben. In de meeste gevallen kosten je toekomstige workarounds meer dan de reparatie nu.

[Maghiel]

Verwijderd schreef op dinsdag 08 januari 2008 @ 14:39:
Alles kan teruggedraaid worden of in ieder geval opnieuw gevuld.

Heb zelf redelijk veel databases gemaakt; en kom je er halverwege (maar liever eerder) achter dat er iets niet klopt/veel problemen oplevert, dan verander je het ontwerp, en ga je niet om de problemen heen friemelen.

Dat neemt niet weg, dat ik van mening ben dat een top10 een top10 is. En dat zijn de 10 meest beluisterde nummers... Dat ze op hetzelfde album staan, zou in mijn optiek van geen belang zijn.

Het veranderen heb je gelijk in, maar ik zei ook bovendien zijn er andere redenen waarom het gesplitst is, beetje teveel werk en irrelevant om hier uit te leggen.

Het is erg lelijk om van een bepaald nummer de radio edit, club edit, dj huppeldepup remix en ringtone versie in de top 10 te hebben. dan heb je in feite hetzelfde nummer 5 keer erin staan. en dit gebeurt helaas nogal veel in de praktijk anders was ik het wel met je eens geweest!

Janoz schreef op dinsdag 08 januari 2008 @ 15:01:
[...]

Ja, maar dat wil je niet weten dus heb je er ook niet veel aan. Je zult het toch op een dergelijke manier moeten doen. Een andere oplossing is om niet 10, maar 10x het maximaal aantal tracks op een album/single op te vragen en dan vervolgens in je eigen code de dubbele albums eruit te filteren.

Verder maakt het geinsert hebben van duizenden records natuurlijk geen kont uit. Een conversiescript kun je gewoon laten draaien en daarvoor maakt het niet uit of het 100000 of 10 items zijn. Al geschreven code kun je blijvend laten werken door views te maken op die nieuwe tabel die op de oude tabellen lijken.

Het loont gewoon bijna altijd om je database model goed te hebben. In de meeste gevallen kosten je toekomstige workarounds meer dan de reparatie nu.

dat wil ik wél weten, alleen mogen ze niet van hetzelfde album zijn!

Een andere oplossing is om niet 10, maar 10x het maximaal aantal tracks op een album/single op te vragen en dan vervolgens in je eigen code de dubbele albums eruit te filteren.

dat vind ik teveel een workaround

voor de rest zie mijn antwoord op de quote hierboven

is er niet gewoon een manier om al te filteren in de query die ik hierboven liet zien? dat moet toch mogelijk zijn?

[bigbeng]

Maghiel schreef op dinsdag 08 januari 2008 @ 15:54:
...
Een andere oplossing is om niet 10, maar 10x het maximaal aantal tracks op een album/single op te vragen en dan vervolgens in je eigen code de dubbele albums eruit te filteren.

dat vind ik teveel een workaround
...

Sorry? Je hebt een slecht uitgenormaliseerd datamodel en dan heb je problemen met een workaround? Gebruik maken van een id-veld voor een link naar twee verschillende tabellen, bah!

Maar goed, je zou eens kunnen kijken of je twee queries kan maken, 1 die de 10 meestgedraaide albums ophaalt en 1 die de 10 meestgedraaide singles ophaalt. UNION eroverheen, ordenen op aantal maal gedraaid en daar dan de top 10 van maken. Okee, je haalt 10 tracks/albums teveel op, maar je hebt wel een relatief overzichtelijke query.

[Maghiel]

bigbeng schreef op dinsdag 08 januari 2008 @ 16:29:
[...]

Sorry? Je hebt een slecht uitgenormaliseerd datamodel en dan heb je problemen met een workaround? Gebruik maken van een id-veld voor een link naar twee verschillende tabellen, bah!

kheb zelf nooit het probleem gezien in 1 id veld voor 2 tabellen, maar goed, kan dat natuurlijk oplossen door een singleid en albumid toe te voegen en type en typeid te laten vallen.
albums en singles moeten wel gescheiden blijven in verschillende tabellen!

bigbeng schreef op dinsdag 08 januari 2008 @ 16:29:
Maar goed, je zou eens kunnen kijken of je twee queries kan maken, 1 die de 10 meestgedraaide albums ophaalt en 1 die de 10 meestgedraaide singles ophaalt. UNION eroverheen, ordenen op aantal maal gedraaid en daar dan de top 10 van maken. Okee, je haalt 10 tracks/albums teveel op, maar je hebt wel een relatief overzichtelijke query.

je snapt denk ik niet helemaal wil, het gaat niet om gedraaide albums of singles, maar gedraaide TRACKS. en die tracks staan dus opgeslagen in main_statistics_listened. alleen mogen er nooit tracks in voorkomen die van eenzelfde album/single afkomen!

[Dido]

Maghiel schreef op dinsdag 08 januari 2008 @ 16:57:
kheb zelf nooit het probleem gezien in 1 id veld voor 2 tabellen, maar goed, kan dat natuurlijk oplossen door een singleid en albumid toe te voegen en type en typeid te laten vallen.

Hou je het probleem dat een single en een album in essentie een identieke rol hebben (drager van het nummer) en dat je daar nu net functioneel mee wilt stoeien op dit moment. Dit is dan dus de eerste keer dat je er tegenaan loopt, dan heb je tot nu toe mazzel gehad

(Doordat ID 123 zowel een album als een single kan zijn is groeperen op die meuk niet echt makkelijker aan het worden)

albums en singles moeten wel gescheiden blijven in verschillende tabellen!

Wat jij wil. Maar als je tegelijkertijd geen workarounds wilt en een simpele query op een lousy 200.000 records te zwaar vindt wordt het toch erg lastig.

Heb je al eens gekeken naar dat voorbeeldje wat ik eerder gaf, en wat je afschoot? Heb je al eens geprobeerd om daar gewoon met een join de stats bij te lezen?

hint:

SQL:

select a.type, a.typeID, max(b.gedraaid) from tracktable a
join statstable b on a.tracj = b.track
group by a.type, a.typeID
order by 3 desc limit 10

Dit geeft je een lijst van de singles/albums waar de meestgedraaide nummers opstaan.

[Maghiel]

Dido schreef op dinsdag 08 januari 2008 @ 17:12:
[...]

Hou je het probleem dat een single en een album in essentie een identieke rol hebben (drager van het nummer) en dat je daar nu net functioneel mee wilt stoeien op dit moment. Dit is dan dus de eerste keer dat je er tegenaan loopt, dan heb je tot nu toe mazzel gehad

(Doordat ID 123 zowel een album als een single kan zijn is groeperen op die meuk niet echt makkelijker aan het worden)

[...]

Wat jij wil. Maar als je tegelijkertijd geen workarounds wilt en een simpele query op een lousy 200.000 records te zwaar vindt wordt het toch erg lastig.

Heb je al eens gekeken naar dat voorbeeldje wat ik eerder gaf, en wat je afschoot? Heb je al eens geprobeerd om daar gewoon met een join de stats bij te lezen?

hint:

SQL:

select a.type, a.typeID, max(b.gedraaid) from tracktable a
join statstable b on a.tracj = b.track
group by a.type, a.typeID
order by 3 desc limit 10

Dit geeft je een lijst van de singles/albums waar de meestgedraaide nummers opstaan.

nou ja, als ik albumid en singleid invoer(en een daarvan is dan 0 als niet van toepassing) is het probleem ook al gedeeltelijk opgelost.

zal ik morgen even mee aan de slag gaan, tis alweer na 5-en dank je vast!

[Janoz]

dat wil ik wél weten, alleen mogen ze niet van hetzelfde album zijn!

Dus wil je het niet . Je hebt immers nog een extra eis.


Ik blijf erbij dat ten eerste je datamodel een beetje brak is. Dan krijg je automatisch workarounds. Daarnaast schiet je normale oplossingen af omdat je vermoed dat het wel niet efficiënt zou zijn, maar kun je ondertussen niet zelf iets beters verzinnen.

Verder kan ik geen enkele legitieme reden verzinnen waarom het onderscheid tussen album en single door verschillende tabellen moet worden gemaakt. Zoals ik eerder al zei, het is een minimale aanpassing. Als je vervolgens op die nieuwe tabel twee views maakt hoef je je applicatie nauwelijks aan te passen.

Trouwens. Dat een nummer meerdere keren in de top 10 kan komen dek je natuurlijk niet af door alleen iets van 1 album toe te laten. Wat nu als een nummer op een single en op een album staat? Of wat nu als een nummer op 2 albums voorkomt?

[Verwijderd]

Waarom doe je zo moeilijk... je applicatie kan ik toch ook uitstekend afhandelen.

Draait een count en group by op je statistieken, haal je 1ste rij op, dit is je nummer 1. knal het albumid/singleid in een array. Haal de 2de rij op uit je stats check of het albumid/singleid in je array voorkomt, zo niet heb je je nummer 2, zowel skip deze track en haal rij 3 op uit je stats. enz enz enz

[Gomez12]

Verwijderd schreef op dinsdag 08 januari 2008 @ 21:58:
Waarom doe je zo moeilijk... je applicatie kan ik toch ook uitstekend afhandelen.

Draait een count en group by op je statistieken, haal je 1ste rij op, dit is je nummer 1. knal het albumid/singleid in een array. Haal de 2de rij op uit je stats check of het albumid/singleid in je array voorkomt, zo niet heb je je nummer 2, zowel skip deze track en haal rij 3 op uit je stats. enz enz enz

Waarbij je met minimaal 10 database query's zit, een app die het moet gaan vergelijken. Maximaal aantal querys valt geen voorspelling voor te doen ( behalve max aantal regels in de db ).

Btw extra vraag, als 1 nummer op 1 cd, 2 verzamel cd's, en 3 singles staat. Moet het totaal dan geteld worden alszijnde :
Het nummer is x keer gedraaid over alles of
Het nummer is x keer gedraaid op de cd x, y keer gedraaid op cd's y en z, en z keer gedraaid op single a,b en c?

Want als het om het nummer gaat zou ik zeggen methode 1, maar met een top40-nr en verzamelcd's denk ik toch dat je met methode 1 redelijk wat andere nrs gaat uitsluiten

[Janoz]

@DotHack: Iets vergelijkbaars heb ik al voorgesteld waarbij je niet een LIMIT 10 doet, maar meer results terug vraagt (voor de zekerheid 10x maximaal aantal nummers op een album, maar het kan natuurlijk wel ietsje minder zijn)

@Gomez: De functionele specificaties van de topicstarter gaan duidelijk over de track. Zou het om een muzieknummer gaan waarbij een nummer op een album, de verschillende versies op een single en de ringtone allemaal meetellen dan is dat zo goed als onmogelijk met dit database model. Dan zul je eerder een tabel met nummers moeten hebben. Hieraan koppel je een tabel met uitvoeringen en vervolgens heb je dan nog een koppeltabel tussen de uitvoeringen en de dragers (waardoor een zelfde versie ook op meerdere CD's voor kan komen. Ik noem het expres niet een CD, maar een drager aangezien je dan ook andere mediums op kunt nemen (ringtone, SACD of DVD bv).

[Maghiel]

@ Janoz, je hebt gelijk dat het datamodel beter moet. Maar dat heb ik nu verder opgeschoven. Het is momenteel erg druk en heb er gewoonweg geen tijd voor nu, andere zaken met hogere prioriteit.

Over een nummer dat op meerdere albums voorkomt: in de praktijk komen deze toch nooit tegelijk in de top 10 voor. Wanneer een nummer populair is, worden vaak ook de andere nummers van een album geluisterd, waardoor die dan ook gelijk in de top 10 kwamen, en dat was eigenlijk het probleem.


Ik ben even met jou query aan het knutselen nu

[ Voor 15% gewijzigd door Maghiel op 09-01-2008 15:55 ]

[Maghiel]

SQL:

select a.type, a.typeID, max(b.gedraaid) from tracktable a
join statstable b on a.tracj = b.track
group by a.type, a.typeID
order by 3 desc limit 10

dat klopt niet helemaal: het aantal keer gedraaid moet namelijk nog geteld worden.

ik ben na wat knutselen op dit gekomen:

SQL:

SELECT 
    `main_tracks`.`id`, `main_tracks`.`type`, `main_tracks`.`typeid`,
    MAX(`count`) AS `times_listened`
FROM
    ( SELECT `trackid`, COUNT(`trackid`) `count`
        FROM `main_statistics_listened`
        GROUP BY `trackid`
    ) AS `stats`, `main_tracks`
GROUP BY `main_tracks`.`type`, `main_tracks`.`typeid`
ORDER BY 4 DESC LIMIT 10

maar daar raakt mysql gruwelijk van over de zeik, op kleine database niet(Showing rows 0 - 9 (10 total, Query took 0.0055 sec)), maar op de productie database wel

Misschien een idee hoe dit te versnellen?