最近由於系統日益複雜的需求系統中各種型別訂單越來越多，原來的這些訂單表已經不能滿足當下的需求，以可擴充套件為目標打算對這些訂單表進行重構，本文只涉及基礎版的設計，對於高併發、分散式等暫不考慮。

        之前的系統訂單按不同業務有不同的訂單表，比如洗車訂單表、噴漆訂單表、內飾清洗訂單表等。在網上找了一些訂單的設計方案，也跟朋友討論了一下幾個設計方案的情況得出如下幾個結果。

方案一：

保持原來的結構不變，每增加一種新的業務需求，就建立對應的訂單表，然後將所有訂單表合併為一個檢視，查詢的操作都在檢視進行。

利：資料庫不需要大的變動，不會影響現有的程式和資料，穩定性比較好

弊：訂單資料的增刪改比較麻煩，設計系統的時候會比較複雜，也容易出錯。每增加一個業務需求，就需要新增新的訂單表，然後加入到檢視中去，還要開發對應的程式，非常不推薦。

方案二：

既然都是要改，那就不考慮大改還是小改了。分析這幾種訂單，然後將通用的欄位拿出來作為訂單基礎表（比如訂單號、訂單狀態、使用者id、訂單型別、價格、時間等訂單表共有的，訂單的增刪改都在這個表上進行），然後將每個訂單獨有的一些欄位再建立訂單明細表（明細表一般不涉及刪除和修改），明細表分別對應各自的業務需求。

利：訂單資料比較清晰，增刪改只需操作訂單基礎表，系統設計會比較精簡，擴充套件性較高

弊：新增一個業務需求，可能需要新增對應的訂單明細表，程式中也要新增一部分操作。另外可能就是維護這些訂單明細表稍微麻煩點。

方案三：

說到方案三不得不說一下mysql5.7的一個新特性json列，就是mysql可以將一列作為json型別儲存資料。那這樣的話我們可以將方案二中訂單明細表都作為一個json列存入訂單基礎表中，這樣所有的訂單資訊都存在訂單基礎表，一個表就可以完成不同業務的訂單。

利：新增業務需求，訂單表和程式基本不需要什麼太大的變動，不需要維護這些訂單明細表。

弊：首要使用json列必須是mysql5.7以上的版本，然後json列的資料操作起來感覺有點麻煩，不友好，所以json列的資料最好只查詢用。

另外json列可以用字串替換，直接用字串存json列，但是這樣資料操作起來還不如json，只是理論上可行。暫時想到這麼幾種方案，具體使用哪種需要根據自己系統的需求，不要硬套，因為我這些是根據我的系統需求做的，只是提供幾種思路，僅供參考。