etc. That way the dates from consecutive brand appearances can be compared by the rank=rank+1 for the datediff() comparison. There already is an autoincrement id column but it can't be used for comparing consecutive dates of the same brand.
Given that, you can do something assuming that the number of reads is at least 20x the number of writes (otherwise it's really not that performant). Basically, the idea is to maintain the `rank` column on each INSERT, UPDATE, or DELETE. Your writes get slow, but your reads get fast. This, essentially, is a cache. You can do this maintenance either in code or using a trigger. MySQL has triggers, so that works out nicely.
My criteria for good software:
Does it work?
Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
I think your brand/date and reverse date/brand index is a great idea for this and all sorts of other applications! I hadn't thought to set them up quite that way in this case.
To maintain the rank would mean searching backward through the table to find the last 'brand' entry and its corresponding rank. I'll investgate triggers and think about how to do it when the new records are being inserted rather than after the fact.
Thanks for all the help! it has been great... Apologies for contaminating a perl forum with what turned out to be a SQL question!