Question

Lets say I have a website that sells widgets. I would like to do something similar to a tag cloud tracking best sellers. However, due to constantly aquiring and selling new widgets, I would like the sales to decay on a weekly time scale.

I’m having problems puzzling out how store and manipulate this data and have it decay properly over time so that something that was an ultra hot item 2 months ago but has since tapered off doesn’t show on top of the list over the current best sellers. What would be the logic and database design for this?

Answer 1

Part 1: You have to have tables storing the data that you want to report on. Date/time sold is obviously key. If you need to work in decay factors, that raises the question: for how long is the data good and/or relevant? At what point in time as the “value” of the data decayed so much that you no longer care about it? When this point is reached for any given entry in the database, what do you do–keep it there but ensure it gets factored out of all subsequent computations? Or do you archive it–copy it to a “history” table and delete it from your main “sales” table? This is relevant, as it has to be factored into your decay formula (as well as your capacity planning, annual reporting requirements, and who knows what all else.)

Part 2: How much thought has been given to the decay formula that you want to use? There’s no end of detail you can work into this. Options and factors to wade through include but are not limited to:

• Simple age-based. Everything before the cutoff date counts as 1; everything after counts as 0. Sum and you’re done.
• What’s the cutoff date? Precisly 14 days ago, to the minute? Midnight as of two Saturdays ago from (now)?
• Does the cutoff date depend on the item that was sold? If some items are hot but some are not, does that affect things? What if you want to emphasize some things (the expensive/hard to sell ones) over others (the fluff you’d sell anyway)?

Simple age-based decays are trivial, but can be insufficient. Time to go nuclear.

• Perhaps you want some kind of half-life, Dr. Freeman?
• Everything sold is “worth” X, where the value of X is either always the same or varies on the item sold. And the value of X can decay over time.
• Perhaps the value of X decreased by one-half every week. Or ever day. Or every month. Or (again) it may vary depending on the item.
• If you do half-lifes, the value of X may never reach zero, and you’re stuck tracking it forever (which is why I wrote “part 1” first). At some point, you probably need some kind of cut-off, some point after which you just don’t care. X has decreased to one-tenth the intial value? Three months have passed? Either/or but the “range” depends on the inherent valud of the item?

My real point here is that how you calculate your decay rate is far more important than how you store it in the database. So long as the data’s there that the formalu needs to do it’s calculations, you should be good. And if you only need the last month’s data to do this, you should perhaps move everything older to some kind of archive table.