SaranacLake Posted February 24, 2019 Share Posted February 24, 2019 My website allows users to purchase various membership plans which in turn gives them varying degrees of access to content and features. I was going to create a "membership_plan" table and call it quits, but then the marketer in me stepped in and posed some interesting questions... - What happens when a given "membership_plan" has a price change? How do you keep track of that? - What happens when a given "membership_plan" has a change to its features? How d you keep track of that? I am more concerned with how do I manage evolving "membership_plans" with what has already been sold?! For example, maybe I sell @requinix a "Platinum" plan today for $50/year, but then this summer i add in free podcasts in that plan, and decide to increase the price to $70/year. I need some way to make sure that Requinix doesn't see a price increase, because he should be locked in for $50/year until the end of his term. The more i think about this the more of a mess it becomes. I suppose all of this is more of a database question, but I figured i would ask it hear since it is also a programming rpblem. I am thinking I have data entities here like: MEMBERSHP_PLAN and PROMOTION and maybe PLAN_HISTORY or PLAN_DETAILS? Looking like there is a many-to-many here, but I could use some advice on how to build this out?! Thanks! Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/ Share on other sites More sharing options...
requinix Posted February 24, 2019 Share Posted February 24, 2019 It's actually pretty simple: you create a brand new plan and make sure people can no longer choose the old one. Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/#findComment-1564737 Share on other sites More sharing options...
SaranacLake Posted February 24, 2019 Author Share Posted February 24, 2019 Just now, requinix said: It's actually pretty simple: you create a brand new plan and make sure people can no longer choose the old one. But doesn't that create a lot of fragmentation? Because now I have "Platinum_v01" and "Platinum_v02" and so on in my database. I was thinking something like this would be better... MEMBERSHIP_PLAN -||--------|<- PROMOS or MEMBERSHIP_PLAN -||--------|<- PLAN_HISTORY The idea being that the "Platinum" plan for the msot part is the same old "Platinum" plan, but the price will certainly change over time and maybe a few features. Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/#findComment-1564741 Share on other sites More sharing options...
requinix Posted February 24, 2019 Share Posted February 24, 2019 11 minutes ago, SaranacLake said: But doesn't that create a lot of fragmentation? Fragmentation? I don't see how. Quote Because now I have "Platinum_v01" and "Platinum_v02" and so on in my database. Yeah. So? What's wrong with having multiple plans? Your business needs change over time, it's okay. Quote I was thinking something like this would be better... MEMBERSHIP_PLAN -||--------|<- PROMOS or MEMBERSHIP_PLAN -||--------|<- PLAN_HISTORY The idea being that the "Platinum" plan for the msot part is the same old "Platinum" plan, but the price will certainly change over time and maybe a few features. And you could, if you wanted. But isn't it starting to get rather complicated? You have to look up pricing at that time, features at that time... It sounds cooler and making it more complex might seem like it's better, but what are you really gaining from it? How much time is it going to take to make this work? What is the risk of something going wrong? Multiple plans fits better into your structures, covers all the requirements, and is easy to implement. I mean, surely you're not going to be changing plans every week, right? You design your plans now because you think they will last, and then you find out later that something needs to change or that you can get more conversions if you alter pricing or features, then you roll out a new plan for those people. 1 Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/#findComment-1564743 Share on other sites More sharing options...
SaranacLake Posted February 24, 2019 Author Share Posted February 24, 2019 44 minutes ago, requinix said: Multiple plans fits better into your structures, covers all the requirements, and is easy to implement. I mean, surely you're not going to be changing plans every week, right? You design your plans now because you think they will last, and then you find out later that something needs to change or that you can get more conversions if you alter pricing or features, then you roll out a new plan for those people. I see your points, except for maybe the last thing... if the only thing that changes on a plan is a rate change, then should I create an entirely new (and basically identitcal) plan just for the rate increase from say $50/yr to $55/year? I could do this this... MEMBERSHIP_PLAN -|----|<- PRICING_HISTORY That way if the price goes up of down I'm covered and don't have to muck up my database with clone records. However, to your earlier point, if things like features change, then sure, create a new record in MEMBERSHIP_PLAN with a comment like "Platinum (Winter 2019)", "Platnum (Summer 2020)", etc. Yes or no? Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/#findComment-1564745 Share on other sites More sharing options...
requinix Posted February 24, 2019 Share Posted February 24, 2019 Still no. I myself have tried the path you're looking at and believe me, it's not fun to work with. There are too many moving parts. Database queries suck. Adds joins to queries that didn't need them. It's just too complicated - and that's really something coming from me because I love over-engineering these things. Maybe don't think of it as changing the price but as taking one plan that was fairly successful and setting up another similar plan with a slightly different price. 1 Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/#findComment-1564746 Share on other sites More sharing options...
SaranacLake Posted February 24, 2019 Author Share Posted February 24, 2019 Just now, requinix said: Still no. I myself have tried the path you're looking at and believe me, it's not fun to work with. There are too many moving parts. Database queries suck. Adds joins to queries that didn't need them. It's just too complicated - and that's really something coming from me because I love over-engineering these things. Maybe don't think of it as changing the price but as taking one plan that was fairly successful and setting up another similar plan with a slightly different price. Fair enough! Psst... I created a most excellent thread asking for help on MVC... ? Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/#findComment-1564747 Share on other sites More sharing options...
requinix Posted February 24, 2019 Share Posted February 24, 2019 2 minutes ago, SaranacLake said: Psst... I created a most excellent thread asking for help on MVC... ? I saw. Just giving someone else a chance to say something. I'll stop by eventually. 1 Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/#findComment-1564748 Share on other sites More sharing options...
maxxd Posted February 26, 2019 Share Posted February 26, 2019 Another option would be to record the package cost to the customer with the specific customer row. A 'current_rate' field or a many-to-many table with `customerID`, `planID`, and `rate` fields. This way you could give discounts or charge somebody more depending on what mood you're in. Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/#findComment-1564839 Share on other sites More sharing options...
SaranacLake Posted February 26, 2019 Author Share Posted February 26, 2019 27 minutes ago, maxxd said: Another option would be to record the package cost to the customer with the specific customer row. A 'current_rate' field or a many-to-many table with `customerID`, `planID`, and `rate` fields. This way you could give discounts or charge somebody more depending on what mood you're in. I decided to go with a m-to-m before you posted. Similar to a textbook Orders ==> Order Details <== Products set up where you have a unit_price and a sale_price, I will do the same (as you also suggest) to allow me the ability to keep track of what price I sell a subscription at to an individual. Quote Link to comment https://forums.phpfreaks.com/topic/308378-plans-promos/#findComment-1564845 Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.