I am focusing on an internet application for any magazine that will permit customers to sign in and renew their monthly subscriptions online. These monthly subscriptions are restored with different algorithm, and Let me acquire some ideas/recommendations regarding how to setup these rules.

This web application connects by having an exterior (third-party) system which has data for that customer. Once the customer logs in, the net application grabs a lot of information out of this third-party system, together with a number known as a "subscription definition ID" which (on the face) denotes the kind of subscription that the customer has. This subscription type might be many years outdated, therefore the web application consists of some "order specifications" (saved inside a database) that includes the present subscribe options, together with information such as the current rate (therefore the cost could be proven towards the user around the order form).

My current idea is to produce a table of subscription definition IDs that map towards the order specs that confirmed subscription definition ID renews. For instance, a regular membership definition ID might denote single-year subscription from 10 years ago, which cost $39.99 in those days within the database, this could map towards the current order specs, which may possess the current cost of $59.99.

This works pretty much theoretically, but as always, there is a catch. Once the subscription definition IDs were setup in older days, they were not always unique. Particularly, one subscription definition ID has extremely different actions, based on context. This subscription definition ID can be used for 1-year monthly subscriptions and 1-year reduced gift monthly subscriptions. Therefore, with all this subscription definition ID, numerous things sometimes happens:

  1. Whether it's single-year subscription, he'll renew while using (current) 1-year subscription.
  2. Whether it's single-year reduced gift subscription and also the customer isn't reviving every other monthly subscriptions, it'll renew like a (current) 1-year full-cost gift subscription.
  3. Whether it's single-year reduced gift subscription and also the customer is reviving other monthly subscriptions, it'll renew like a (current) 1-year reduced gift subscription.

I am unsure how you can generalize this within the database, especially because this complication only happens with one record. I essentially need a method to model that above logic that could work using the records that aren't special cases. I possibly could always do that in code, but I am unwilling to invest e-commerce-y logic within the code itself (especially just in case the issue happens later on, along with other subscription definition IDs).

What's the easiest method to model this mixture of information and logical rules?

It is not something I'd normally suggest, but because there's only one subscription definition ID and it has been the problem for several years (therefore this can be a stable business rule), I would recommend hard-coding the behavior with this ID.

The secret here's to parameterize the company logic, which means developing a parameters table. The overall situation is the fact that any type of subscription is qualified for many other type of renewal, so you've a table that maps Original Subscription to Qualified Renewal(s). After this you have general code that examines a user's monthly subscriptions and shows the 1 option or a listing of choices for renewal.

For much of your cases, basically understand what you're saying, the initial subscription just maps to itself. You've just got that one situation where some monthly subscriptions map to special cases.

However, should you choose it by doing this, you've got a nice general-purpose renewal system that's now underneath the admin's control, as they possibly can customize the mappings without waiting that you should provide new code.