近期看了idilent的文章《使用物件導向技術解決商品打折問題》，文後有讀者提出要求：如果不同商品的折扣不同怎麼辦？或者有買一百送五十這種方式，或不同會員等級的折扣不同。怎麼處理？」idilent認為打折這個問題並不是能夠通過乙個的字段就可以解決的。有不同的會員，不同的產品，不同的銷售計畫，而這些也是在不停的不變化和增加的。而會員和產品的打折，以及店慶等打折，雖然都是折扣，但是很難抽象成資料庫中的乙個字段或者幾個字段，不使用程式解決，而希望只是通過改變資料庫中的資料，在目前階段實現起來可能還比較困難。
之前我曾參與過乙個影碟出租銷售管理系統的專案開發，負責其中的架構和
資料建模工作，儘管最後該專案由於某些客觀原因而被放棄，但是該專案中也有打折優惠這方面的功能需求，我也思考過這一塊的
資料建模。其實，我們可以把商品銷售打折這樣的商務規則分解成幾個部分，分析各個部分之間的關係，從中找出關鍵點，再將其泛化
資料建模，即可實現讓使用者自己定義打折規則。下面開始分析商品銷售打折的商業規則：
一套商品銷售管理資訊系統，必定存在下面兩個實體：顧客，商品，打折這種商業規則一定是圍繞著這兩個實體以及相互間的關係而制定的。回顧我們的購物經歷，打折的需求應該可以分為三種：
1)對特定商品的折扣一般有如下幾種情況：按售價進行一定百分比的打折；原價->**(某個時間段內進行的)的打折；**優惠銷售(如購買某一(幾)種商品後即可按較低的**或折扣購買另一(幾)種商品)。
2)對顧客的的打折方式一般採用會員制，即是按會員等級在交費時直接給與一定的折扣優惠，或者在會員累積消費一定金額後給以一定比例的返點優惠，該方式需要顧客辦理會員卡之類的身份標識卡。
3)對總額的打折方式一般是顧客消費後送出的限定最後使用期限的代金券。
注意到上面三大類折扣方式分解開來，都離不開商品，所以這三種打折方式都是商品的共有屬性，應該歸入到商品表中。另外，一般大型超市多擁有多個分店，而且可能出現各個分店的打折規則略有不同的情況，上面的三種打折規則得同相應的分店一一對應。最後，
資料建模大致如下：
店鋪表(shop)
名稱 型別 約束條件 說明
shop_id int 無重複 店鋪標識，主鍵
shop_namevarchar(40)不允許為空 店鋪名稱
shop_addrvarchar(80)不允許為空 店鋪位址
……商品類別表(ware_type)
名稱 型別 約束條件 說明
type_id int 無重複 商品類別標識，主鍵
type_namevarchar(20)不允許為空 商品類別名稱
father int 不允許為空 該類別的父類別標識，如果是頂節點的話設定為某個唯一值
layer char(6) 限定3層,初始值為000000類別的先序遍歷，主要為減少檢索資料庫的次數
商品表(ware)
名稱 型別 約束條件 說明1
轉《商品銷售打折自定義的資料建模》
近期看了idilent的文章 使用物件導向技術解決商品打折問題 文後有讀者提出要求 如果不同商品的折扣不同怎麼辦？或者有買一百送五十這種方式，或不同會員等級的折扣不同。怎麼處理？idilent認為打折這個問題並不是能夠通過乙個資料庫的字段就可以解決的。有不同的會員，不同的產品，不同的銷售計畫，而這些...
自定義的資料型別
c 中有一種資料型別稱為列舉 enumeration 型別，它允許使用者自己來定義一種資料型別，並列出該資料型別的取值範圍。定義列舉型別的語法格式為 enum 型別名 定義列舉常量的位置應該在程式首次使用該型別名之前，否則程式無法識別該型別。列舉型別中列出的常量稱為列舉常量，它並不是字串也不是數值，...
rtos zephyr執行緒的自定義資料
每個執行緒都有乙個自定義的32資料域，這個資料域自由執行緒能夠自己訪問。預設情況下是為0.通過配置 config thread custom data使能自定義資料，因為預設情況下執行緒是不支援自定義資料的。通過呼叫介面 k thread custom data set 和 k thread cus...