How can I model both data and logic in a database?_问答_开发者

I'm working on a web app for a magazine that will allow users to log in and renew their subscriptions online. These subscriptions are renewed based on a set of rules, and I'd like to get some ideas/recommendations on how to set up these rules.

This web app interfaces with an external (third-party) system that has data for the subscriber. When the subscriber logs in, the web app grabs a bunch of information from this third-party system, including a number called a "subscription definition ID" which (ostensibly) denotes the type of subscription that a subscriber has. This subscription type may be several years out of date, so the web app contains a set of "order specifications" (stored in a database) that consists of the current subscribe options, along with information like the current rate (so the price can be shown to the user on the order form).

My current idea is to create a table of subscription definition IDs that map to the order specification to which a given subscription definition ID renews. For example, a subscription definition ID might denote a 1-year subscription from ten years ago, which cost $39.99 back then; in the database, this would map to the current order specification, which would have the current price of $59.99.

This works pretty well in theory, but as usual, there's a catch. When the subscription definition IDs were set up back in the day, they weren't always unique. In particular, one subscription definition ID has wildly different behaviors, depending on context. This subscription definition ID is used for both 1-year subscriptions and 1-year discounted gift subscriptions. Therefore, given this subscription definition ID, a number of things can happen:

If it's a 1-year subscription, he'll renew using the (current) 1-year subscription.
If it's a 1-year discounted gift subscription and the subscriber is not renewing any other subscriptions, it'll renew as a (current)开发者_如何转开发 1-year full-price gift subscription.
If it's a 1-year discounted gift subscription and the subscriber is renewing other subscriptions, it'll renew as a (current) 1-year discounted gift subscription.

I'm not sure how to generalize this in the database, especially since this complication only occurs with one record. I basically need a way to model that above logic which could also work with the records that aren't special cases. I could always do this in code, but I'm reluctant to put all this business-y logic in the code itself (especially in case the problem occurs in the future, with other subscription definition IDs).

What's the best way to model this combination of data and logical rules?

The trick here is to parameterize the business logic, and that means creating a parameters table. The general case is that any kind of subscription is eligible for some other kind of renewal, so you have a table that maps Original Subscription to Eligible Renewals(s). You then have general code that examines a user's subscriptions and shows the 1 option or a list of options for renewals.

For most of your cases, if I understand what you are saying, the original subscription just maps to itself. You just have this one case where some subscriptions map to special cases.

However, if you do it this way, you have a nice general-purpose renewal system that is now under the admin's control, as they can modify the mappings without waiting for you to provide new code.

It isn't something I would normally suggest, but because there is only one subscription definition ID and this has been the situation for a number of years (therefore this is a stable business rule), I suggest hard-coding the behaviour for this ID.