淺談商城活動設計
如題：淺談商城活動設計
標題改成“淺談商城活動的數據庫設計”可能更加合理。
文章背景
為什麽要吐槽，為什麽要寫這篇文章
本來我在弄大數據搜索，自己玩的不亦說乎，雖然感覺數據庫設計不合理，但我可以數據清洗，弄到自己的搜索引擎裏，自己隨便玩，所以當時感覺在爛的數據庫設計和我關系不大，只要我把數據清洗好，弄到自己的引擎裏我的搜索正常，準確，問題不大。但忽然有一天老大跑來說ERP對接需要你來lead一下，然後一兩個月帶著搗亂的產品妹妹，和沒有經驗開發弟弟搞了ERP的簡單對接，然後老大又說咱們商城庫存總有超賣，想辦法設計搞一下，然後就是一入侯門深似海，跳進火坑出不來。原來我們的商城是這樣的一個商城，商城底層設計開發成型有了將近一年時間，我從半路接手，商城要運行，重構要繼續。我大概用了一個多月的時間對接了ERP，用了兩個多月的時間重構了創建訂單和生成訂單的功能，然後又用了兩個多月的時間完成我們的會員功能的訂單重新計算。大概半年的時間，我已經到了心力憔悴，看代碼，開會都頭疼的地步，所以實在是忍不住了。
為什麽要發到網上
想吐糟，但是最近在練習控制情緒，所以用近乎平和的語氣控制自己的憤怒情緒，寫下這篇商城活動數據庫設計，供所有人吐槽，大家吐槽，才是真的吐槽。
本來是想發公司內部員工所有研發參考討論的，但實在擔心引起公憤，而且因為反應設計問題，數據庫問題被領導批評多次，而且每每不歡而散，所以也不想在跟領導反應了，發到網上跟所有的領導反應吧。（可以說是某某公司的內部資料哦）~其實和某某公司也沒有卵關系，大家所有的商城不是或者不應該是都是這樣設計更合理麽。
扯淡完畢。
文章正文
首先我在這裏明確一點，這裏我要說的活動設計不是指商城怎麽設計活動能最吸引客戶吸引用戶，能引來更多流量，能幫助商城賣出更多是商品或打響更高的知名度。
首先大概了解一下我們商城的活動，我們商城的活動有4類，分別是：
1、滿贈換購，意思就是購買滿了M元之後加N元可以領一個小禮品，這種活動和超市裏的那種活動一模一樣，我們認為N元換購的這個小禮品單價價為N元。
2、滿M元減N元，意思就是滿了M元之後立減N元，這種活動應該算是超市活動或其他電商購物活動滿多少元送券，一樣的，只是我們直接減錢了。在具體的程序計算中，我們不能算M元減N元就完事了，我們需要具體到每件商品減少了N’元。活動可以這樣設置，程序也可以這樣展示，但是計算是不能單純用文字或者口述來計算的。
4、M錢N件，意思就是打包給M塊錢，直接拿走N件商品。這種活動和超市裏那種甩賣一樣，但程序計算時同樣需要精確計算，要算到每件商品N’元。
在現在眾多的多的APP中除了我們商城的這些活動之外，現在很多商城還有各種各樣的活動，例如：
5、在買商品買之前可以領券，然後用券直接抵錢購買，券和錢一起使用，滿多少元可以用券，和咱們的優惠券一模一樣
6、還有是可以用錢買券，然後用直接券購買。比如，30元買個50元的券，然後用50元的券買商品。
這些活動都是有區別的，各有各的優點和不足，我們不做討論，除了這些活動，還有其他活動，
如：限時搶購活動，團購活動，等等這些都是活動。
那麽如何把活動進行抽象，進行合理的數據庫設計。這是值得認真思考的一個問題。
首先第一，
活動有本身的些屬性，比如上邊說的那4~6，8種活動中，要提取公共的屬性，比如活動的名字，時間，和其他的一些基本的屬性這裏不多贅述，這些屬性都很簡單，做過數據庫設計的人一般都能想到，那麽除了這些屬性，所有這些活動的本質是什麽。
換購，滿減，M元M件，限時搶購，團購，還有那些共同點。
規則！對！我們把這些活動的核心的東西提取處出來通成為規則。
這樣應該就可以看到一個更加清晰和合理和邏輯更強的設計。
就是活動下有很多規則，或者說活動是一些規則的組合，換句話說活動就是一組規則。
那麽要怎麽設計，通過上邊的分析和提取，大概的設計就有可初步的端倪，
活動主表有自己的屬性，一個活動有很多規則，規則子表。
大概的設計至少應該是這樣
Activity(
int id pk,
string name,
timestamp start_time,
timestamp end_time,
timestamp create_time
)
ActivityRule(
int id pk,
int activity_id,
XXXXXX type
XXXXXX condition
XXXXXX result
)
ActivityTags(
int id pk,
int activity_id,
string name
)
從上邊的結構可以這樣理解，我們創建一個活動，活動下邊有一個或多個規則，活動還有一堆標簽。
舉個簡單例子，我們創建一個滿M元減少N元的多動，比如：悅詩風吟618大促，滿199減少30，滿299減少50，
那麽對應的數據存儲就是：
活動表： 618大促活動
活動規則表：
規則1：滿299減少50，對應的存儲結構可能是：condition >=299，result -50
規則2：滿199減少30，對應的存儲結構可能是：condition >=199，result -30
大概就是這個樣子，具體的存儲結構可以更加具體的詳細的在討論。
再比如限時搶購，那麽它的condition就是什麽，result是什麽，
在比如團購，那麽它的condition就是什麽，result是什麽，
最後，最後，最後一個問題，活動的商品和活動怎麽關聯，怎麽知道哪些商品參加了那個活動，活動的商品，怎麽存，怎麽關聯。
這個問題，我本來想關聯力度越小越好，想關聯到ActivityRule上，但是回頭想想關聯在Activity上可能也是一個非常棒的選擇。
大概會是這個樣子
ActivityGoods(
int id pk,
int activity_id,
int goods_id,
numberic goods_prie,
string goods_image
)
這樣的一張表大概是定義了活動和商品的關系，也就是說，說明了那些商品參加了什麽活動，
商品價格本身可以不用，但是有些特殊的活動或商品或修改商品在活動中的價格，所以把價格也拿過來，可以修改活動中的價格。
關於image,可能是參加活動時商品的圖片也和一般的不一樣，會更有吸引力。
以上是我對商品，商城活動設計的一些思路和想法，並不是正式的代碼，而要轉換成代碼要思考和設計的更多，更詳細。
除了活動的設計，還有咱們倉庫的設計，按照這個思路大家可以想想倉庫的設計比如包郵規則，拆包規則，等等。
說這些東西是希望對大家對比現在數據庫的設計進行反思和思考。
現在有些東西正在重構，我知道底層數據庫表的改動和變化對程序的變動有多大，會對大家造成多大的工作量和影響，也知道每次發版我們的時間有多緊張，但是最最希望看到的重構是全新的設計。
大家想想通過這樣的設計，這樣的思路是不是更加清晰，明朗，通過這種方式的改進，程序是不是可以更加優雅和優化。
這種方式還可以更加有效的使用緩存，內存，規則引擎等一些高級的東西。
這樣寫來，心情會好一些，以後在有實在忍不住的想法，在陸續更新出來。
歡迎大家吐槽~
淺談商城活動設計