Hi Bill, On Thu, Feb 26, 2009 at 7:18 PM, Bill Moseley <moseley at hank.org> wrote: > I was thinking of using a ledger that tracks purchases and then > individual transactions. > > Description | minutes | SMS messages > ------------------------+---------+--------------- > 1/1/09 Purchase plan A | 1000 | 200 > 2/1/09 SMS | | -1 > 2/1/09 Called 555-1234 | -12 | > 3/1/09 Called 555-3212 | -44 | > 3/1/09 SMS | | -1 > > So the ledger recorded a purchase and a number of transactions. This is basically what I suggested, except you don't have anything representing an account state in your data model, and you've mixed "credits" and usage, which I don't agree with. You have transaction history and you must derive the account state. I don't agree that doing otherwise would be "managing totals" anymore than tracking an x month subscription to a service is managing totals. You have an account credit against which you are drawing down through usage. > But, I can see two problems. First, the expires date is tracked > elsewhere. So, say the plan says if you do not renew by the expires > date then you lose your minutes. ... > Hum, that's not very pretty. For one thing, "active" is a > de-normalized value (because an inactive account is one where the > expires date has past. I would define an inactive account as an account which has no un-expired minutes. You track minute lots separately, each lot with its expiration date (which can be updated based on your renewal business logic). > And the other issue is what if mid way through "Plan A" where > minutes are counted individually they purchase "Plan B" where each > call has a minimum of 5 minutes even if you talk for just one minute? > Do we have to finish out Plan A until it expires or do we start > counting by Plan B as soon as they sign up even if half way through > Plan A? I don't see how this has any impact on how you structure the "account state" data. This only has impact on how you track usage. Of course, if you mix the two... -- Matt Warden Cincinnati, OH, USA http://mattwarden.com This email proudly and graciously contributes to entropy.