Open glenl opened 8 years ago
Both the popularity metrics will require new .dat files so we might want to wait until (if) we start using a database. That said, you could still do it with .dat file if we wanted. Not a trivial change.
Is it possible to leverage datafiles/musiccache.dat to create a set of .dat files with the statistics for composer, instruments, styles, which would be later used for html generation.
Having a db to query for this is more elegant, obviously.
If the problem is complexity, I am trying to work out if the following SQL is more complex than the above algorithm.
SELECT composer, COUNT(composer) AS cc
FROM muPiece AS piece
WHERE piece.composer IN (SELECT composer FROM muComposer)
GROUP BY composer
ORDER BY cc DESC
LIMIT 25
;
I understand that a database inserts a level of complication but I would argue that sequential data files become more complex and inefficient as the archive grows. Hmm. Still thinking.
BachJS 415
Traditional 125
MozartWA 89
GiulianiM 80
BeethovenLv 74
HoretzkyF 60
HandelGF 57
SchubertF 55
SorF 55
DiabelliA 36
CarcassiM 34
SchumannR 34
ChopinFF 30
MontePd 29
Anonymous 26
Mendelssohn-BartholdyF 24
TitelouzeJ 23
VerdiG 20
BurgmullerJFF 19
CzernyC 19
JoplinS 18
KnjzeF 18
HaydnFJ 16
AguadoD 15
SatieE 13
Anything that gets us away from musiccache.dat is going to pay off. "Count how many times the ID is found in musiccache.dat" is a big, hairy, awful method or methods.
Originally mentioned by @dominicus in issue #32 : Use a popularity metric to order browse lists.
Advanced, or perhaps another issue: allow users to switch between alphabetical or popularity sorting, use cookies to remember the user's choice.
n.b., we only do dynamic pages on search results so the advanced task will take some work.
_Downoad counts: _ The only good way to do this is with a database.