实施基于政策、基于时间和基于客户的定价[关闭]答案

【问题标题】：Implementing Policy based, time based and customer based pricing [closed]实施基于政策、基于时间和基于客户的定价[关闭]
【发布时间】：2011-12-30 18:35:46
【问题描述】：

我在为我们的 SKU（库存单位）实施基于政策、基于时间和基于客户的定价时遇到问题。到目前为止，我已经为基于时间的定价创建了下表

 SKUPrices  
ID Pk  
SKUID FK_To_Sku  
DateFrom  
DateTo  
Price

我相信这个架构可以很好地处理基于时间的定价（不过我需要社区对其进行审查），但我不知道如何处理基于客户的定价（如果我们想以补贴价格向一些客户出售少量 sku时间段）和基于政策的定价（如果在某个时间段内根据某些政策出售，则对 sku 应用补贴费率）。

【问题讨论】：

如果 SKU 的价格有冲突怎么办？你是根据最高/最低价格来挑选的吗？
某个特定时间段的价格将是唯一的，因为我们将确保时间段不重叠。
政策和客户定价能否同时对同一个 SKU 生效？如果没有，那么将 customerID 和 PolicyID 添加到 SKUPrices 表似乎可以解决问题。这假设业务规则已经到位，表明当客户购买某物时要选择什么订单，或者组织可能只是遵循最便宜的方法；在这种情况下，由于可能有 3 种不同的选择，假设客户有资格获得基于客户和基于政策的价格，系统将选择相关日期范围的最小值（价格）。
是的，基于客户和政策的定价可以同时生效
例如：SKU 1234 的基本价格为 12.50，介于 1/1/2012 00:00:00 和 1/31/2012 23:59:59 之间。客户 A 和 B 的客户定价 11.50 对 SKU 1234 在 2012 年 1 月 15 日 00:00:00 和 2012 年 1 月 31 日 23:59:59 之间生效，针对 SKU 1234 的政策规定将价格再降低 10%适用于 2012 年 1 月 24 日 00:00:00 至 2012 年 1 月 31 日 23:59:59 之间的购买。如果在 2012 年 1 月 1 日进行购买，则为 12.50。制作于 2012 年 1 月 16 日，客户 A B 为 11:50，其他客户为 12:50。如果客户 A/B 在 2012 年 1 月 30 日购买，则为 11.50-10%，其他人为 12.50-10%。这是正确的吗？

标签： sql database database-design architecture

【解决方案1】：

实现上述要求的一种非常简单的方法是只添加 2 列，如下所示：

SKUPrices
------------------
ID Pk  
SKUID FK_To_Sku
CustomerId FK_to_Customer
PolicyId FK_to_Policy  
DateFrom  
DateTo  
Price

然后，如果您想输入基于日期的值，您可以只为客户和策略 ID（NULL 或 0）提供默认值。如果您想存储客户或政策的特定价格，请添加客户或政策 FK。

这是一个非常简单的价格存储模式，但它可能足以满足您的需求。您可能还需要处理价格等级（不同数量的不同价格）或其他需求。也许你已经可以通过你的政策解决这个问题了，我不知道。

【讨论】：

此架构是否正确规范化？
它不是绝对标准化的（正如 Mark Bannister 已经指出的那样）。但是，我使用了这两种方法（这种方法和 Mark 提出的多表方法），并且必须说，在必须获得价格时处理多表总是很麻烦。这将主要是一个查找表，所以我会选择“不惜一切代价进行标准化”。
还有一个补充：数据库设计始终取决于您的当前和未来要求。您必须始终考虑将来可能会遇到哪些要求。这就是促使您决定选择一种或另一种模式的原因。

【解决方案2】：

为客户定价和基于政策的定价设置单独的表格：

CustomerPrices
------------------
ID Pk  
SKUID FK_To_Sku
CustomerId FK_to_Customer
DateFrom  
DateTo  
Price

PolicyPrices
------------------
ID Pk  
SKUID FK_To_Sku
PolicyId FK_to_Policy  
DateFrom  
DateTo  
Price

在通过每个表的单独左外连接计算价格时，包括对客户和政策定价表的检查。

【讨论】：

请解释一下为什么我们应该创建两个表而不是一个，如果我使用 MicSim 解决方案有什么缺点
实际上是三个表 - 这两个是您原来的 SKUPrices 表的补充。 MicSim 的解决方案未正确规范化，因为您将在同一表中看到依赖于客户和/或政策的价格与仅依赖于 SKU 的价格。