2011-01-14 69 views
1

不久,我將開始一個項目,這個項目相當於一個本質上屬於配置產品的電子商務應用程序。這個問題是關於如何實施可能會每天都在變化的定價方案,所以我們希望將定價邏輯從代碼和數據庫中提取出來,但不是以一種導致數據庫完成所有工作的方式。「動態」定價系統

基本思想是這樣的,有5個屬性。您從每個屬性中選擇一個選項。然後你開始添加產品到你的購物車。您添加的所有產品都將擁有5個屬性(屬性會影響定價)。添加產品後,您可以對其應用修改(這些屬性也將應用於修改)。因此,我們現在得到的是一個產品(它有一個固定的基本價格)和一些關於它的信息(這將修改價格),以及零個或多個修改(其具有固定的價格)和一些關於它們的信息(這將修改價格)。修改也可能產生額外費用。例如,如果A公司使用這個軟件,他們使用BASE_PRICE + $ 50 * NUM_WHIRLIGIGS爲他們的商品定價,並且該商品有一個修改,增加了一個WHIRLIGIG,這個價格必須反映出來。

您是否知道不同定價系統的任何示例,在確定如何設置時可能會發現有用?你有更好的想法嗎?

我目前最好的想法是下面,你可以跳過它,如果你不好奇的方法的細節,只是想獲得正確的應答!

對於任何給定的項目(或項目的集合)的公司可以使用特殊的接口設置這將隨後進行解釋,並在運行時進行評估定價公式。

所以對於PRODUCT_A,該公司可能投入類似BASE_PRICE + WHIRLIGIG_UPCHARGE * NUM_WHIRLIGIGS。當軟件定價時,軟件會查看該項目的WHIRLIGIGS數量,以及通過修改添加的WHIRLIGIGS數量。

有沒有人有實施這種解釋器的經驗?後來如何?這很困難/麻煩嗎?

在此先感謝所有精彩的輸入,我一定會得到。 :P

回答

0

通常,這通常是使用具有組件的產品捆綁包處理的。因此,具有5個附加子組件的產品不會是基本+ 5 *附件,而是SUM(基本,附加,附加,附加,附加,附加)。

所以你的產品表可以是自我指涉或有某種聯繫表,說其子產品都允許連接該產品的。

以我的經驗,定價通常是存儲在一個產品/客戶或合同爲基礎的,所以這是另一個表。

然後實際的訂單本身包含產品包。如果訂單是報價,則價格將凍結(直到報價到期)。

當報價或訂單變成發票,此時的定價或者從主定價或報價,這取決於定價定時範例鎖定。

+0

它可能有助於指出配置的產品是廚房櫥櫃。不幸的是,任何給定的製造商都會以不同於最後一種的方式爲其產品定價。其中一些實際上可以做如下事情:PRICE = CABINET_BASE_PRICE * FINISH_UPCHARGE +(BASE_COST_OF_DOOR * FINISH_UPCHARGE * NUM_DOORS) – 2011-01-14 18:48:46