优惠券使用限制的数据库设计

Question

在为电子商务应用程序实施凭证功能时，我需要实施凭证使用限制，我计划的一些限制

1. 产品
2. 排除产品
3. 产品类别
4. 排除类别
5. 电子邮件/客户限制

目前我们支持以下两种凭证，可以选择创建自定义凭证类型，所有这些优惠券类型都借助于鉴别器（使用休眠）在单个表中进行维护。

1. 序列优惠券
2. 促销优惠券。

这些只是我在初期阶段所针对的几个。我的主要困惑是关于数据库设计和这些voucher usage与Voucher的限制。我无法确定哪种是最佳的Map方式数据库中的这些限制。

我应该针对所有这些限制使用单个表并与Voucher表有关系，还是将所有相似类型的限制组合在一个表中并与Voucher表关联。

作为附加信息，我们使用hibernate将我们的实体映射到数据库表。

Answer 1

这似乎是一个非常开放和自由形式的要求。一些问题：

您尝试建模的业务规则有多复杂？如果您允许（商业）用户定义他们自己的优惠券，可能性很高，他们会提出一些漂亮的拜占庭式规则和组合。如果你必须支持任何，那么你就会遇到问题。

数据库的任务是如何处理这些数据？存储“凭证定义”，当然，但那又是什么？运行计数或报告？分析使用了多少，按谁/何时/如何/用于什么？或者只列出过去一年中使用/生成的内容？

您将拥有什么样的数据量？每张凭证定义一个条目，或打印/签发的每张凭证？ （如果是后者，你可以使用每个凭证一个条目，计算发行数量吗？）我们是在谈论数十，数百或数百万的优惠券吗？

如果它完全是自由格式，如果他们只是想要一个没有认真分析的列表，如果总体积很小，请考虑使用blob字段而不是面向细节的列。类似于大文本字段和数据输入框的用户将“输入定义凭证的任何其他标准”。 （你甚至可以使用XML来做到这一点。）丑陋，你无法轻易分析数据，但如果目标太大或太分散而且你不会使用所有详细数据，可能是必要的。

最后一点：只有选定产品的优惠券才能用于创建优惠券后添加的产品。适用于所有但所选产品的凭证可以用于随后创建的产品。该逻辑可适用于任何凭证限制标准。这两种方法都有其优点，确保用户清楚他们正在做什么。

Answer 2

如果我了解您的工作情况，那么只有一个表可以解决所有限制问题，因为这意味着每Voucher有1行，而不同的限制列中有多个值。

您更难以更新，提取和转换限制值。

在我看来，每个限制类型应该有一个表，并用Voucher表映射它们。但是，添加新限制会更容易。

Answer 3

我个人会提到你的第二个提案......将所有类似类型的限制分组到一个表中，该表引用了凭证表。

我要补充一点，你可以在同一张桌子上处理包含和排除。

所以我使用的结构是：

Voucher                           (id, type, etc...)
VoucherProductRestriction         (id,voucher_id,product_id,include)
VoucherProductCategoryRestriction (id,voucher_id,product_category_id,include)
VoucherCustomerRestriction        (id,voucher_id,customer_id)
VoucherEmailRestriction           (id,voucher_id,email)

...其中include列可以是布尔值，如果您想要将凭证限制为该产品或类别，则为true;如果要将其限制为除特定产品或类别以外的任何产品或类别，则为false。 / p>

如果我正确理解您的上下文，那么对同一凭证同时包含和排除限制是没有意义的（尽管有多个相同类型可能是有意义的）。如果对两种类型的限制使用单个表，则可以更好地处理和检查。

Answer 4

建议：

让valid-products和valid-categories代替Exclude-products和Exclude-categories更合理吗？
拥有Customer-Creditgroup表将导致我们拥有valid-customer-group表。

BTW在当前设计中我们可以有一个凭证定义表，我将其称为voucher-type表。
关于限制：
在RDBMS级别中，您只能装饰性地说明两种类型的表约束：

• 唯一标识属性（键）
• 引用回相同或其他表的子集要求 （外键）

实现所有其他类型的表约束（如多元组约束或转换约束）需要您开发过程数据完整性代码。
当凭证要销售给特定客户以获取特定产品时，我们需要检查排除元素的有效性，这可以通过应用程序的数据库级别或业务逻辑中的触发器来完成。