Popularity metric

[glenl]

Originally mentioned by @dominicus in issue #32 : Use a popularity metric to order browse lists.

• First entry in Instrument list should be the instrument whose count is specified in the most pieces.
• First entry in Composer list should be the composer with the most pieces.

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.

[ksnortum]

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.

[dominicus]

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.

• For each composer ID in composers.dat, count how many times the ID is found in musiccache.dat
• Store composer, total piece count, and alphabetic sequence, into new composer-stats.dat file
• similar process for instruments and styles
• New functions in htmlgen to leverage these new .dat files to generate lists sorted by top-X by count, alphabetical, etc. for html page generation

Having a db to query for this is more elegant, obviously.

[glenl]

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

[ksnortum]

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.