談一談商城活動設計

如題：淺談商城活動設計

標題改爲「淺談商城活動的數據庫設計」可能更加合理。

文章背景

爲何要吐槽，爲何要寫這篇文章

原本我在弄大數據搜索，本身玩的不亦說乎，雖然感受數據庫設計不合理，但我能夠數據清洗，弄到本身的搜索引擎裏，本身隨便玩，因此當時感受在爛的數據庫設計和我關係不大，只要我把數據清洗好，弄到本身的引擎裏個人搜索正常，準確，問題不大。但突然有一天老大跑來講ERP對接須要你來lead一下，而後一兩個月帶着搗亂的產品妹妹，和沒有經驗開發弟弟搞了ERP的簡單對接，而後老大又說我們商城庫存總有超賣，想辦法設計搞一下，而後就是一入侯門深似海，跳進火坑出不來。原來咱們的商城是這樣的一個商城，商城底層設計開發成型有了將近一年時間，我從半路接手，商城要運行，重構要繼續。我大概用了一個多月的時間對接了ERP，用了兩個多月的時間重構了建立訂單和生成訂單的功能，而後又用了兩個多月的時間完成咱們的會員功能的訂單從新計算。大概半年的時間，我已經到了心力憔悴，看代碼，開會都頭疼的地步，因此實在是忍不住了。

爲何要發到網上

想吐糟，可是最近在練習控制情緒，因此用近乎平和的語氣控制本身的憤怒情緒，寫下這篇商城活動數據庫設計，供全部人吐槽，你們吐槽，纔是真的吐槽。

原本是想發公司內部員工全部研發參考討論的，但實在擔憂引發公憤，並且由於反應設計問題，數據庫問題被領導批評屢次，並且往往不歡而散，因此也不想在跟領導反應了，發到網上跟全部的領導反應吧。（能夠說是某某公司的內部資料哦）~其實和某某公司也沒有卵關係，你們全部的商城不是或者不該該是都是這樣設計更合理麼。

扯淡完畢。

文章正文

首先我在這裏明確一點，這裏我要說的活動設計不是指商城怎麼設計活動能最吸引客戶吸引用戶，能引來更多流量，能幫助商城賣出更可能是商品或打響更高的知名度。
這裏我要說的商城活動設計是指在程序開發過程當中，數據庫的設計，怎麼設計數據表結構，怎麼存儲，怎麼展現，怎麼使用。
首先大概瞭解一下咱們商城的活動，咱們商城的活動有4類，分別是：
一、滿贈換購，意思就是購買滿了M元以後加N元能夠領一個小禮品，這種活動和超市裏的那種活動如出一轍，咱們認爲N元換購的這個小禮品單價價爲N元。
二、滿M元減N元，意思就是滿了M元以後立減N元，這種活動應該算是超市活動或其餘電商購物活動滿多少元送券，同樣的，只是咱們直接減錢了。在具體的程序計算中，咱們不能算M元減N元就完事了，咱們須要具體到每件商品減小了N’元。活動能夠這樣設置，程序也能夠這樣展現，可是計算是不能單純用文字或者口述來計算的。
三、滿M件減N元，意思就是某種商品或者商品組合滿了M件以後直接減小N元，這種活動和那種打包一塊兒賣的活動很相似。一樣和2同樣須要精確的計算，要算到具體的每件商品減小了N’元。
四、M錢N件，意思就是打包給M塊錢，直接拿走N件商品。這種活動和超市裏那種甩賣同樣，但程序計算時一樣須要精確計算，要算到每件商品N’元。
在如今衆多的多的APP中除了咱們商城的這些活動以外，如今不少商城還有各類各樣的活動，例如：
五、在買商品買以前能夠領券，而後用券直接抵錢購買，券和錢一塊兒使用，滿多少元能夠用券，和我們的優惠券如出一轍
六、還有是能夠用錢買券，而後用直接券購買。好比，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,多是參加活動時商品的圖片也和通常的不同，會更有吸引力。

以上是我對商品，商城活動設計的一些思路和想法，並非正式的代碼，而要轉換成代碼要思考和設計的更多，更詳細。
除了活動的設計，還有我們倉庫的設計，按照這個思路你們能夠想一想倉庫的設計好比包郵規則，拆包規則，等等。

說這些東西是但願對你們對比如今數據庫的設計進行反思和思考。

如今有些東西正在重構，我知道底層數據庫表的改動和變化對程序的變更有多大，會對你們形成多大的工做量和影響，也知道每次發版咱們的時間有多緊張，可是最最但願看到的重構是全新的設計。

你們想一想經過這樣的設計，這樣的思路是否是更加清晰，明朗，經過這種方式的改進，程序是否是能夠更加優雅和優化。
這種方式還能夠更加有效的使用緩存，內存，規則引擎等一些高級的東西。

 

這樣寫來，心情會好一些，之後在有實在忍不住的想法，在陸續更新出來。

歡迎你們吐槽~