如何在数据库中对数据和逻辑进行建模？答案

【问题标题】：How can I model both data and logic in a database?如何在数据库中对数据和逻辑进行建模？
【发布时间】：2011-05-08 16:30:53
【问题描述】：

我正在为一本杂志开发一个网络应用程序，该应用程序允许用户登录并在线续订他们的订阅。这些订阅是根据一组规则续订的，我想就如何设置这些规则获得一些想法/建议。

此网络应用程序与具有订阅者数据的外部（第三方）系统交互。当订阅者登录时，Web 应用程序会从这个第三方系统中获取大量信息，包括一个称为“订阅定义 ID”的数字，它（表面上）表示订阅者拥有的订阅类型。这种订阅类型可能已经过时了几年，因此 Web 应用程序包含一组“订单规范”（存储在数据库中），其中包含当前订阅选项以及当前费率等信息（因此价格可以在订购单上显示给用户）。

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

这在理论上很有效，但像往常一样，有一个问题。当年设置订阅定义 ID 时，它们并不总是唯一的。特别是，一个订阅定义 ID 具有完全不同的行为，具体取决于上下文。此订阅定义 ID 用于 1 年订阅和 1 年折扣礼品订阅。因此，给定这个订阅定义 ID，可能会发生很多事情：

如果是 1 年订阅，他将使用（当前）1 年订阅进行续订。
如果它是 1 年折扣礼品订阅并且订阅者没有续订任何其他订阅，它将作为（当前）1 年全价礼品订阅进行续订。
如果它是 1 年折扣礼品订阅并且订阅者正在续订其他订阅，它将作为（当前）1 年折扣礼品订阅进行续订。

我不确定如何在数据库中概括这一点，尤其是因为这种复杂情况只发生在 one 记录中。我基本上需要一种方法来对上述逻辑进行建模，该方法也可以处理不是特殊情况的记录。我总是可以在代码中执行此操作，但我不愿意将所有这些业务逻辑放在代码本身中（尤其是在将来出现问题的情况下，使用其他订阅定义 ID）。

对这种数据和逻辑规则的组合进行建模的最佳方法是什么？

【问题讨论】：

标签： database business-logic business-rules

【解决方案1】：

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

对于您的大多数情况，如果我理解您的意思，原始订阅只会映射到它自己。您只有这种情况，其中一些订阅映射到特殊情况。

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

【讨论】：

这基本上是我最初的想法，但也有一些...*丑*逻辑在起作用，这使这种方法变得复杂。
根据我的经验，uglier 逻辑也可以解析为参数（即表格），如果以正确的方式看待的话。这是一个非常大的话题，太大了，无法在评论中讨论。我的博客（在我的个人资料中列出）经常涉及到这一点。

【解决方案2】：

这不是我通常会建议的，但是因为只有一个订阅定义ID并且多年（因此这是一个稳定的业务规则），我建议对这个 ID 的行为进行硬编码。

【讨论】：

我认为你可能是对的，不幸的是......不过，听到一些针对此类问题的通用解决方案还是很酷的。这不是我很了解的领域。