代码之家 › 专栏 › 技术社区 › mipadi

如何在数据库中对数据和逻辑进行建模?

business-rules business-logic database

2

mipadi · 技术社区 · 13 年前

我正在为一家杂志开发一个网络应用程序,允许用户登录并在线续签订阅。这些订阅是根据一组规则更新的,我想获得一些关于如何设置这些规则的想法/建议。

此web应用程序与具有订阅服务器数据的外部(第三方)系统接口。当订阅者登录时,web应用程序从这个第三方系统获取一堆信息,包括一个名为“订阅定义ID”的数字,这个数字(表面上)表示订阅者拥有的订阅类型。此订阅类型可能已过期数年,因此web应用程序包含一组“订单规范”(存储在数据库中),其中包含当前订阅选项,以及当前费率等信息(因此价格可以在订单上显示给用户)。

我当前的想法是创建一个订阅定义ID表,该表映射到给定订阅定义ID续订的订单规范。例如,订阅定义ID可能表示十年前的一年订阅,当时的费用是39.99美元;在数据库中,这将映射到 现在的 订单规格,当前价格为59.99美元。

这在理论上很有效,但和往常一样,有一个陷阱。当年设置订阅定义id时,它们并不总是唯一的。特别是,根据上下文的不同,一个订阅定义ID具有非常不同的行为。此订阅定义ID用于1年订阅和1年折扣礼品订阅。因此,给定此订阅定义ID,可能会发生以下情况:

如果是1年的订阅,他将使用(当前的)1年订阅续订。
如果是1年折扣的礼品订阅,并且订阅方没有续订任何其他订阅,则它将续订为(当前的)1年全价礼品订阅。
如果是1年折扣礼品订阅,并且订阅方正在续订其他订阅,则它将续订为(当前)1年折扣礼品订阅。

我不知道如何在数据库中概括这一点,特别是因为这种复杂情况只发生在一记录。我基本上需要一种方法来模拟上面的逻辑,它也可以处理不是特殊情况。我总是可以在代码中这样做,但我不愿意将所有这些业务逻辑放在代码本身中(尤其是在将来出现问题时,使用其他订阅定义id)。

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

2 回复 | 直到 13 年前

1

0

Ken Downs 13 年前

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

对于您的大多数情况,如果我理解您的意思,那么原始订阅只会映射到它本身。你只有一个例子,有些订阅映射到特殊情况。

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

2

0

user359040user359040 13 年前

这不是我通常会建议的,但是因为只有一订阅定义ID 和这种情况已经存在很多年了(因此这是一个稳定的业务规则),我建议对此ID的行为进行硬编码。