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

Question

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

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

目前我们支持以下2种类型的优惠券,可选择创建自定义凭证类型,所有这些优惠券类型都借助于鉴别器(Hibernate使用)在单个表中进行维护.

1. 串行优惠券
2. 促销优惠券.

这些只是其中我在初始stage.My主要针对混乱很少是关于这些数据库设计和限制voucher usage使用Voucher.我现在无法确定这是地图数据库中的这些限制,最好的方式.

我应该为所有这些限制使用单个表并与Voucher表有关系,或者将所有类似类型的限制组合在一个表中并与Voucher表关联.

作为附加信息,我们使用hibernate将我们的实体映射到DB表.

Answer 1

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

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

数据库应该对这些数据负责什么？存储"凭证定义",当然,但那又是什么？运行计数或报告？分析使用了多少,按谁/何时/如何/用于什么？或者只列出过去一年中使用/生成的内容？

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

如果它是完全自由格式的,如果他们只是想要一个没有认真分析的列表,如果总体积很小,请考虑使用blob字段而不是面向细节的列.类似于大文本字段和数据输入框的用户将"输入定义凭证的任何其他标准".(你甚至可以使用XML来做这件事.)丑陋,你不能轻易地分析数据,但如果目标太大或太分散而且你不打算使用所有那些详细数据,那么可能是必要的.

最后一点:只有选定产品有效的优惠券不能用于创建优惠券后添加的产品.除了所选产品之外的所有产品均可使用的优惠券可用于随后创建的产品.该逻辑可适用于任何凭证限制标准.这两种方法都有其优点,确保用户清楚他们正在做什么.

Answer 2

如果我了解您在做什么，那么您将遇到只有一个表用于所有限制的问题，因为这意味着每个限制行 1 行，Voucher并且不同限制列中有多个值。

您将更难更新、提取和转换限制值。

在我看来，您应该为每种限制类型创建一个表，并将它们与Voucher表进行映射。但是，您可以更轻松地添加新的限制。