Welcome Guest, Not a member yet? Register   Sign In
Software Design Problem: VPN Accounts
#1

[eluser]parham90[/eluser]
Hi there,

My client has requested me to make him a website through which people could sign up for a VPN account, choose a service they want to buy (E.G. a monthly service for 30 days and for $30, etc), enter their bank payment information, and he could approve the information, causing their service to be active since that moment. However, no matter how I think, I haven't been able to figure out any solutions for implementing parts of this system.

Since he wants to add/remove/edit current available VPN services and their prices and the number of days each of them would be active for, I thought, well, I could put the services in one table (containing id, name, price, and days (I.E. the days this service would be active for)), and then put the approved ones in the requests table (containing service_id, user_id, and approval_date). the approval_date would be the date the service has been approved, and to figure out the service remaining time (he needs it to be displayed to the user), I would just deduct the approval_date from the current date, and deduct the result from the services.days. In other words:

$remaining_days = $services->days - ($todays_date - $requests->approval_date)

All fine so far. However, the user can, at any time, login and purchase another service to be appended to his current one. In other words, if he has a service that lasts for 30 days, he can buy another that lasts 30 days too, effectively making it 60 days for him. Now the problem is evident; where does the service that is newly bought go? Would I need a cron job to swap values around every day? Since I do not like this nasty cron-oriented approach, I thought of another thing.

I thought I could just store the days that he has paid for (E.G. 30), and every time he logs in, I'd do the same I did before; get the approval date of his request, deduct it from today, and then deduct the result from the number of days in the database. When he wants to purchase another service to be added to his current one, sure, I'd just increase the users.days (the days he has paid for) by the services.days value of the new service. And the flaw in this strategy is also evident now; what if the admin wants to have, say, different names but the same days? Or different prices and the same days?

So, I'm stuck. I would really appreciate it a lot if you could help a beginning programmer relieve his headaches. Smile

Thanks a lot, for the help offered in the past. I'm sorry if I have forgotten to say "thank you" at times; if this has happened, it was because I was too happy about my problem being solved that I just pressed alt+f4 and began coding. *smiles*
#2

[eluser]n0xie[/eluser]
Can't you just have a start_date and an end_date with an associated 'price'. Then if he renews his subscripten, either change the end_date or add another row where the start_date = end_date previous deal + 1?

Or maybe I'm not really understand what the problem is.
#3

[eluser]parham90[/eluser]
I didn't think of that. I like your second suggestion more, but there is a problem in that one, too. The client wants the kind of service the user is currently using to be displayed. If I add another row with the new service, it'd be a mess trying to figure out which one he's using now. Maybe not much when there is two or three rows for the same user, but what if he has used a hundred services? Going through them, I think, would take a long time when the table gets big. Just an assumption though. I don't have a scientific basis for it.

And another thing. The client, as the admin, wants to be able to change the service the user has subscribed to (E.G. if he later on calls and says he wants to change the service and such). So, the data needs to be highly dynamic.

Thanks a lot for the suggestion so far.
#4

[eluser]n0xie[/eluser]
For your first problem finding what subscription a certain client is currently using, would be a simple query finding where the current date is between the start_date and end_date. Not really a very heavy query and one you could either cache or use a view for (showing for every customer/client the 'current' subscription details).

If he wants to change the service, the same applies. Get the row where the current subscription resides and just change the subscription_type. If you are normalising your DB you probably have a table subscription_type (with an associated cost etc.). Changing the type would automatically change the subscription cost etc.
#5

[eluser]parham90[/eluser]
Yes, The subscription_type table is the services table. My problem, however, is not the cost, but the number of days. Let's say that the user has paid for 30 days subscription, but has mistakenly chosen 10 days subscription. He tells the admin to change it for him. Now, if the admin changes the subscription_type_id to the other one, yes, the cost and such could be obtain by looking it up in the table containing types of subscriptions and their associated prices. However, the start_date and the end_date somehow have to be calculated, and the end_date needs to be changed. Just now though, something occurred to me. When the admin confirms the new subscription, the number of days for that particular subscription could be obtained (E.G. 30 days) and then added to the start_date, and then the end_date could be replaced by the new result. Smile That could work?
#6

[eluser]n0xie[/eluser]
Yeah that could work. Obviously there are several ways to solve a problem, but this one sprang to my mind. Someone else might have a different solution though.




Theme © iAndrew 2016 - Forum software by © MyBB