個人數據庫設計實踐（一）

　　兜兜轉轉，忽然發現我如今已是一個老司機了，一直寫代碼都很忙，沒有把不少點點滴滴的記錄下來，今天開始就開始一個系列，分析當年我接觸或者我設計過的表結構，有好有壞，有歡喜也有淚水。不少實踐經驗來自於踩了一個又一個的坑，從如今的角度去回想，在設計的時候若是那麼作，也許我就不須要改代碼了……

　　歡迎各位在評論區討論，我只是想分享一下見解，也許有高人有更好的解法。如下案例從個人實踐中簡化而來，個別命名或者設計請勿對號入座，字段名等也是隨便寫的，只做示例。

 

問題：一個流程管理的模塊如何設計表結構

需求細節：產品的需求大約是這樣，一個訂單取消退貨的流程，中間有審批環節，全部人都經過之後，能夠執行取消動做，全部的退訂申請都須要有時間記錄。

Round1

開發疑問：

（此處心裏暗暗的罵產品經理一千遍，又來搞我，一句話需求。）

數據量多大？不知道

審覈動做須要記錄什麼？審覈人，審覈時間。

審覈人有幾個？3個，銷售主管，銷售總監，財務

 

Round2

產品看了一下，彷佛和他說的差很少，沒毛病。轉過一圈後問，咱們能夠獲取到每一個取消訂單的耗時嗎？媽蛋，二次需求或者說沒把需求一次說全。這個時候開發就須要自行幫產品經理腦補。那麼

申請退款的發起人不必定是客戶，是否是也須要記錄？

即便審覈完成，最後執行退貨動做也須要耗時間，那麼退貨開始和結束時間其實須要另外的兩個字段來記錄？

OK，那麼把各類時間都給它加上。這個時候設計上沒什麼難度，難度是誰知道產品經理給你漏了什麼關鍵需求……

 

 

Round3

產品經理退下以後，給銷售經理打了個電話，據說大家有一個退貨的需求？

是，是，最近不是315嘛，客戶要退，那麼就必須給退啊，客戶是上帝啊。哦對了，咱們這裏退貨還要分全退和部分退，這個能夠支持嗎？

什麼鬼？那若是部分退，我是否是還要收手續費？

沒錯啊，財務是這麼定的，30天內免費退換貨，30天后要按比例收。

媽蛋，我讓產品經理和你來細化一下需求。

（此處和產品經理撕逼100遍……）

細緻的分析：

退貨有類別的區分，退貨其實須要按照操做流程，退貨內容，審覈流程等將表細分，經過一個統一的退貨id來關聯。

操做流程等的記錄建議分離開來，不然之後擴展需求會有隱患。

相關的表設計修改以下圖：

cancellation_info:退貨信息，算是主表

cancellation_audit:退貨審批

cancellation_product:退貨產品及明細

(備註：

1. 退貨產品及相關信息這裏用到了主從表，爲何這麼用或者也許有其餘設計，這裏不做展開，由於我實際案例中碰到的就是這樣。
2. 也見過把退貨產品加一個類別區分後直接放入訂單表的設計，這樣之後統計算某產品銷售總數確實是方便了，和訂單分開2張表這樣的設計也是能夠接受)

 

 

Round4

OK，終於基本搞定銷售經理的需求了，那麼再給財務打了個電話確認需求。

喂，據說咱們這裏有一個退貨的需求和您確認一下。

好啊，如今退貨審批簡化了，我這裏不須要審批，只須要執行，銷售那邊確認完，算好退款金額給我，我只執行退款。

什麼？……

（心中默默的哭泣）

疑問點：

流程須要變動嗎？變動頻率是多少？

審覈流程是單向的流程嗎？例如取消緣由沒寫清楚，是執行退回操做，以後同一筆退訂申請能夠再走審覈流程，仍是必須另起一個流程？

分析：

流程變化這種事很難控制，因此流程和時間節點記錄不能用橫表來擴展，這樣的後果就是一旦流程變動，就要變動數據表。

橫向的表也不能處理跳回和反覆執行的流程。

現今的系統設計時，操做人操做時間等的記錄都須要更完善，因此能考慮的都給它考慮上，加上各類note，memo，記錄各類異常狀況或者備註以防萬一。

新的audit表再也不是按cancellationid對應一條記錄，而是一個cancellationid對應多條記錄，並有了獨立的auditid。並且每一步審覈人均可以獨立的記錄result和memo，記錄會更詳盡，各個審覈時間也有了一個統一的字段，以後統計某一個退貨審覈的耗時，能夠用cancellationid來檢索，最大最小時間相減便可。另外，我我的的建議是將退貨的發起時間和執行完成時間也記錄在此。

 

Others

實際案例中，還有不少不少的細節，如財務須要記錄憑證和其餘事物。銷售那裏還有退貨地址等等

銷售那裏9成會提說有一個當前的退貨狀態的實時報表，因此在cancellation_info里加個狀態標誌位等，方便實際應用我以爲也是能夠考慮的設計。

 

總結

我以爲數據表設計2個主要思辨方向：一個是業務驅動，一個是統計驅動。

業務驅動是說，業務需求須要你把各類數據記錄下來，沒有記錄之後就作不了相關的功能，而後咱們按照各類數據庫設計的模式記錄數據。統計驅動是說知足了基本業務流程須要後，不少數據的實際應用主要是各類統計報表中，要考慮到統計報表時獲取數據的方便性。在設計時，兼顧考慮2方面的需求，這個案例主要說的是業務相關的驅動，要統計審覈時間等又與統計驅動有關。

設計多個表其實對於開發來講沒有什麼難度，難度在於業務經驗，預知可能的變化點，提早作好規劃。一個好的產品經理若是能及早的想到這些點，那麼開發就能夠少走不少的彎路。若是產品經理幫不了忙，那麼只有靠本身，多和各個實際業務打打交道。

流程記錄，步驟記錄，時間點記錄，建議用不要用橫向設計。