2011-12-30 86 views
1

我無法爲我們的SKU(庫存單位)實施基於策略,基於時間和基於客戶的定價。到目前爲止,我已經創造下表以時間爲基礎的定價實施基於策略,基於時間和基於客戶的定價

SKUPrices 
ID Pk 
SKUID FK_To_Sku 
DateFrom 
DateTo 
Price 

我相信這個架構可以處理基於時間的定價以及(我需要它的社區審覈雖然),但我無法弄清楚如何處理基於客戶定價(如果我們想在一段時間內以補貼價格向某些客戶出售少量skus)和基於政策的定價(如果某些政策出售某些時間段,補貼價格將適用於skus)。

+0

如果SKU的價格有衝突怎麼辦?你根據最高/最低價格選擇? – Anurag 2011-12-30 09:44:46

+0

價格在某些特定時間段將是唯一的,因爲我們將確保時間段不重疊。 – 2011-12-30 09:48:35

+0

政策和客戶定價可以在同一時間在同一個SKU上生效嗎?如果不是,那麼將customerID和PolicyID添加到SKUPrices表似乎可以解決問題。這假設業務規則已經到位,表明當客戶買東西時要選擇什麼訂單,或者組織可能只是遵循最便宜的方法;在這種情況下,由於可能存在3種不同的選擇,因此假設客戶有資格獲得基於客戶和政策的價格,系統將選擇相應日期範圍內的最小(價格)。 – xQbert 2011-12-30 10:00:36

回答

2

一個實現上述要求,將只需添加這樣的2分列非常簡單的方法:

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

然後你可以只向客戶提供和策略ID(NULL0)的默認值,如果你想輸入基於日期的值。如果您想存儲客戶或政策特定價格,請添加客戶或政策FK。

這是一個非常簡單的價格存儲模式,但它可能滿足您的需求。您可能還想要考慮價格比例(不同數量的不同價格)或其他需求。也許你已經可以通過你的政策解決這個問題,我不知道。

+0

這個模式是否正確歸一化? – 2011-12-30 10:33:19

+0

這並非絕對正常化(正如Mark Ba​​nnister已經指出的那樣)。但是,我使用了兩種方法(這是Mark提出的一個和多個表格),並且必須說在獲得價格時處理多個表格總是一件麻煩事。這將主要是一個查找表,所以我打算「不要不惜一切代價正常化」。 – MicSim 2011-12-30 14:05:21

+0

另外還有一點:數據庫設計總是取決於你的*當前*和*未來*的要求。你必須總是考慮未來可能會對你造成什麼影響。這就是應該將你的決定推向一個或另一個模式。 – MicSim 2011-12-30 14:10:26

1

成立了客戶和基於策略的定價不同的表:

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 

由獨立的左外計算價格時加入到每個表包括對客戶和政策定價表檢查。

+0

請解釋一下爲什麼我們應該創建兩個表格而不是一個,如果我使用MicSim解決方案,有什麼缺點 – 2011-12-30 11:07:28

+0

它實際上是三個表格 - 這兩個表格除了您的原始SKUPrices表格之外。 MicSim的解決方案標準化不當,因爲您將在同一個表中獲得依賴於客戶和/或策略的價格,這些價格僅依賴於SKU。 – 2011-12-30 11:19:15