views:

67

answers:

3

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?

+2  A: 

you could just count the sales for the last month/week/whatever, and sort your items according to that.

if you want you can always add the total amonut of sold items into your formula.

knittl
I guess what I'm trying to figure out is how to make them decay on a rolling week or month.
Chris Sobolewski
@Chris: Count sales within determined dates.
OMG Ponies
You're saying something along the lines of making a database entry every time a unit is sold along with the date it was sold, then count them?I suppose that would work, and was a heck of a lot easier than what I was coming up with!
Chris Sobolewski
+1  A: 

You might have a table which contains the definitions of the pointing criterion (most sales, most this, most that, etc.), then for a given period, store in another table the attribution of points for each of the criterion defined in the criterion table. Obviously, a historical table will be used to store the score for each sellers for a given period or promotion, call it whatever you want.

Does it help a little?

Will Marcouiller
If only I could pick two answers. Both yours and Philip Kelley's helped a TON.
Chris Sobolewski
Thanks Chris! You at least mentioned that I helped! This is nice when you get to know you helped another programmer. :-) Thanks for the up-vote! :-)
Will Marcouiller
+2  A: 

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.

Philip Kelley