談一談倉庫表單表設計

如題「倉庫單表設計」，只談一張表。

原本想命題爲「淺談簡單倉庫的數據庫設計」的但發現仍是命題太大，
倉庫設計，設計的東西太多了，庫存，進庫，出庫，日誌，盤點等等等等，很是多，並且很細，因此寫完後再次修改命題，就談一張表的設計。
全部作電商的只要有庫存的概念的必定會半生有倉庫的概念，像淘寶京東這樣還有店鋪的概念。
像店鋪，這些暫時先不談，之後我想說了在細聊。今天想談的是簡單的倉庫設計，就設計一張表，倉庫表單表怎麼設計。
爲何想談這個，爲何必定要談，也是由於實在忍不住了，最近更是頭疼的要命，憋屈指數到了200%了，不談不快。
爲何會這樣，爲何不談不快，首先爲了平復一下我受傷的小情緒，先吐個槽，我就不說某司了，直接說咱們公司吧。
咱們也作電商，有電商的業務和模塊，咱們有本身的商城，雖然比較low，但咱們也是麻雀雖小五臟俱全，而後具體五臟位置可能找不到在哪，但咱們仍是有的。
咱們有本身的商城，商城就有促銷，促銷就有促銷活動，上一篇說過了促銷活動該怎麼設計，促銷表我也就不在吐槽了，這裏就不在說了。
而後，咱們還有庫存，咱們的庫存還超賣，超賣這個是一個更深，更廣的話題，之後有的是時間詳談，咱們重構最初的初心就是想控制庫存，控制超賣的。
不事後來演變太快，庫存在有效的範圍內控制住以後，重構的味道就變了，就這裏先不說了。咱們還有倉庫，咱們不但有倉庫，還有不一樣的倉庫，好比說保稅倉，普通倉，香港倉，國外的倉庫。
來看看咱們的程序員是怎麼設計咱們的倉庫表的，在促銷表裏有惟一的一條記錄，促銷表，對你沒看錯就是促銷表，p_type=1, p_postage={"1": 49, "2": 88, "3": 88, "4": 49}
先不談咱們的促銷表的設計結構，合不合理或怎麼樣的。促銷表是作什麼，存儲什麼信息的，這不用說。
那麼我們這條記錄的表示的是什麼，這個類型爲1的數據要特別特別的特殊處理，有且僅有一條，
JSON串表示的意思是某類型的倉庫的包郵條件，某類型是什麼概念。整個的意思就是全部是1類型的倉庫滿49元包郵，2類型的倉庫滿88元包郵。
我在重構時看到咱們的存儲居然是這樣的一個存儲，咱們的結構居然是這樣的一個結構，我整我的是崩潰的，那種崩潰，那種奔潰呀~
稍微有數據庫設計常識的人會這樣設計數據庫，我也是醉了。我跟老大，部門老大反應這樣問題，也是一把辛酸一把淚，那個憋屈指數200%是絕對的。
最後沒有辦法我把那個倉庫寫成了視圖，可是我仍是感受如魚刺在喉，那個噁心程度沒法言表，沒有辦法，我在想是否是我對程序或者設計要求過高了。
這一條祕密的記錄，若是不是耳提面命，口傳身教，若是不把相關的代碼所有翻看一遍，我是不管如何都找不到他在哪裏的。
因此我感受咱們的程序特別神奇，不知如何就運行成功了，數據正常，特別牛，哈哈，哈哈。
好了，吐槽完畢，

那麼具體該怎麼設計倉庫這塊，具體就是這個倉庫表了，
首選，咱們要真正的去了解咱們的倉庫，不說特別詳細仔細的瞭解，
可是至少應該把倉庫的一些特性瞭解一個大概清楚，咱們看到了，咱們上邊說過了咱們有保稅倉，普通倉，香港倉等。
保稅倉，咱們可能有重慶保稅倉，寧波保稅倉等等，
普通倉，咱們可能有天津倉，北京倉等等，
香港倉，咱們也只有香港倉了，呃~
正真瞭解倉庫的人應該都會知道保稅倉在發貨是還有價格限制，好比發貨打包的一個包裹總金額不能超過2000元，倉庫對具體一我的天天的發貨總金額是否是有特殊的限制，等等。
香港倉發貨打包的一個包裹總金額不能超過1000元，一個包裹裏不能多於3個商品，等等一些特殊的限制。
做爲一個開發設計人員，咱們畢竟不是倉庫管理人員，咱們能夠不用所有了解倉庫的全部，但這些基本的東西，在開發設計時，需求也必定會提到，因此仍是應該值得了解一下的。
而後就是倉庫發貨，必定會有物流公司對接，那麼倉庫使用哪一個物流公司，咱們給不給用戶包郵費，達到什麼條件包郵費，郵費時多少。這些應該都是咱們須要瞭解的東西。
好了，咱們基本上把改了解相關的一些東西弄清楚了，那麼該怎麼設計。

上邊咱們看到了，咱們有個倉庫類型的概念，好吧，那咱們也弄個類型吧。
其實自我感受咱們真的沒有必要什麼倉庫類型，還要單獨爲倉庫類型設計張表，自我感受這是多此一舉。
好吧，先無論填不填足了，有就有吧，即使是有了咱們還能夠不用。
那麼這個類型表該怎麼設計，這個應該是最簡單了，不用懷疑就是你想的那樣
warehouse_type(
int id pk,
string name
)
就是這樣，使用的話就是
1 普通倉
2 保稅倉
3 香港倉
徹底看不出存在的意義。

OK，接下來該咱們的主角登場了，倉庫表。

倉庫表該怎麼設計，咱們能夠看到咱們的倉庫有包郵不包郵，還有限購，這些東西該怎麼提取和抽象，最終怎麼設計怎麼使用。
我初版的設計大概是這個樣子
warehouse(
int id pk,
string code,
string name,
numric threshold_money,
int threshold_number,
int type,
numric postage,
numric postage_condition
)
全部的這些設計咱們只討論主要的屬性，固然還有其餘的屬性，好比啓用不啓用，刪除不刪除，建立時間等等，那些咱們不討論，只說重點。
自增主鍵不用說，我大概認爲是這樣，一個倉庫，有倉庫編碼，名稱，
threshold_money這個我定義的是上邊說的咱們達到了多少錢了拆包，剛纔說了保稅倉一個包裹只能不大於2000，用戶買3300的商品必須是兩個或以上的包裹才行。
threshold_number這個我定義的是上邊說的咱們達到了多個少數要拆包，好比剛纔說的香港倉一個包裹裏邊上邊個數不能多於3個，那麼用戶買5個也是必需要拆的。
倉庫類型，郵費，和包郵條件。因此說了感受上邊那個倉庫類型沒有任何卵用，強行關聯也行。
固然可能會有人辯駁說若是咱們沒有任何一個保稅倉，可是仍是想看到一個保稅倉的類型的，沒有保稅倉，就沒有保稅倉這個類型嗎，固然這麼想也無可厚非，我確實也沒法辯駁。
因此我感受無關緊要，若是沒有，我什麼也不說，若是有我也舉手同意。
以上就是我初版的設計了，當時自我感受良好，在使用時，若是那些不須要拆包的倉庫設置某個默認值檢到默認不拆包的值直接跳過。在使用上也沒有任何問題，一切良好。
並且就這個設計應該是可以知足很大部分的簡單倉庫設計了，可是追求仍是要有的，我就是一個追求完美的男人，哈哈。

這個一版的設計若是細想老是讓我感受怪怪的，不是味道，但也挑不什麼毛病，可是就是哪裏有點彆扭。

說過了這是我初版的設計，那麼在上一篇談活動設計的時候我也提到點到了倉庫的設計，隨後我又想若是這個倉庫設計也用規則這種設計來設計會不會更好。
那麼第二版的設計就呼之欲出了，大概是這樣子，把倉庫再拆，拆成倉庫基本信息和倉庫規則信息，以下：
warehouse(
int id pk,
string code,
string name,
int type,
numric postage
)
warehouse_rule(
int id pk,
int warehouse_id,
XXXX condition,
XXXX result
)
這樣理解，就是一個倉庫下有一個或多個規則。舉例說明，好比：
普通倉，只有一個包郵的規則，滿49元包郵。
規則1，condtion:total_price>=49，result:postage=0
保稅倉，在普通倉的基礎上又新增一條規則，就是滿2000要拆包，
規則1，condtion:total_price>=88，result:postage=0
規則2，condtion:total_price>2000，result:split
香港倉，在保稅倉的基礎上又加一條規則，
規則1，condtion:total_price>=88，result:postage=0
規則2，condtion:total_price>1000，result:split
規則3，condition：total_number>3，result:split

固然具體的 細節，怎麼定義condtion和怎麼定義result，能夠在細化討論，可是大概方向就是這個這樣子的。
這樣看，這一版的設計要比初版高端的多，感受這個就很不同，特別棒，爲本身點贊。哈哈

而後談一下郵費的設計，郵費這塊，我怎麼想的，
郵費這東西應該是交給物流的，應該是和選的物流公司有關，一個倉庫固然能夠選多個物流公司了，
因此我想倉庫應該是和多個物流公司發生關係，而郵費是物流公司要求倉庫發貨支付的，從這句話的描述中，你們應該能想到些什麼。
郵費是物流公司的屬性，倉庫沒有郵費的屬性，倉庫的郵費是物流公司的郵費報價，大概是這個樣子。

可是目前據觀察全部的電商，大概的樣子這樣基本能知足需求，並且用戶在購物的那個時刻根本是不關心你倉庫和物流的關係，只關心包不包郵，郵費多少。（固然有人會問使用什麼物流，這是題外話，不考慮）具體支付給誰，用戶確定第一認爲就是支付給你了，因此能夠暫時不用想那麼多，郵費按照上邊的設計基本能知足需求，因此不用在想那麼多了，固然多想一想必定是有好處的。