如何在数据库中建模数据和逻辑？

Question

我正在为一本杂志的网络应用程序工作，该应用程序将允许用户在线登录和续订订阅。这些订阅是根据一系列规则进行更新的，我希望得到关于如何设置这些规则的一些想法/建议。

此Web应用程序与具有用户数据的外部（第三方）系统接口。当用户登录时，Web应用程序从第三方系统获取一串信息，其中包括一个称为“订阅定义ID”的数字，该数字（表面上）表示订阅者拥有的订阅类型。这种订阅类型可能会过期几年，所以Web应用程序包含一组“订单规范”（存储在数据库中），它由当前订阅选项以及当前速率等信息组成（因此价格可以是向订单上的用户显示）。

我目前的想法是创建一个预订定义ID表，该表映射到给定预订定义ID更新的订单规范。例如，订阅定义ID可能表示10年前的1年订阅，当时价格为39.99美元;在数据库中，这将映射到目前的订单规格，其当前价格为59.99美元。

这在理论上工作得很好，但像往常一样，有一个问题。当订阅定义ID在当天重新建立时，它们并不总是唯一的。具体而言，取决于上下文，一个订阅定义ID具有非常不同的行为。此订阅定义ID用于1年订阅和1年打折礼品订阅。因此，鉴于这种订阅定义ID，许多事情都可能发生：

1. 如果它是一个1年订阅，他会使用更新（当前）1年订阅。
2. 如果这是1年的特价礼品订购，并且订户没有续订任何其他订阅，它将作为（当前）1年全价礼品订购续订。
3. 如果这是1年的打折礼品订阅，订阅者正在续订其他订阅，则它将续订为（当前）1年折扣礼品订阅。

我不知道如何在数据库中概括这一点，特别是因为这种并发症只有一个记录发生。我基本上需要一种方法来模拟上面的逻辑，它也可以用于不是特殊情况的记录。我总是可以在代码中做到这一点，但我不愿意将所有这些业务逻辑放在代码本身中（特别是在未来发生问题时，以及其他订阅定义标识）。

建立数据和逻辑规则组合的最佳方式是什么？

Answer 1

这里的诀窍是参数化业务逻辑，这意味着创建一个参数表。一般情况是，任何类型的订阅都有资格享受其他类型的续订，因此您有一张将原始订阅映射到合格续订的表格。然后，您将拥有检查用户订阅的一般代码，并显示1选项或续订选项列表。

对于大部分的情况下，如果我理解你说的话，到原认购只映射到它自身。你只有这种情况，一些订阅映射到特殊情况。

但是，如果你做这种方式，你有一个很好的通用更新系统，现在是管理员的控制之下，因为他们可以修改映射，而无需等待为您提供新的代码。

Answer 2

这是不是我通常会建议，但因为只有一个订阅定义ID 和这一直是数年（因此，这是一个稳定的业务规则）的情况下，我建议硬编码这个ID的行为。