谈一谈仓库表单表设计

如题“仓库单表设计”，只谈一张表。

原本想命题为“浅谈简单仓库的数据库设计”的但发现仍是命题太大，
仓库设计，设计的东西太多了，库存，进库，出库，日志，盘点等等等等，很是多，并且很细，因此写完后再次修改命题，就谈一张表的设计。
全部作电商的只要有库存的概念的必定会半生有仓库的概念，像淘宝京东这样还有店铺的概念。
像店铺，这些暂时先不谈，之后我想说了在细聊。今天想谈的是简单的仓库设计，就设计一张表，仓库表单表怎么设计。
为何想谈这个，为何必定要谈，也是由于实在忍不住了，最近更是头疼的要命，憋屈指数到了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，能够在细化讨论，可是大概方向就是这个这样子的。
这样看，这一版的设计要比初版高端的多，感受这个就很不同，特别棒，为本身点赞。哈哈

而后谈一下邮费的设计，邮费这块，我怎么想的，
邮费这东西应该是交给物流的，应该是和选的物流公司有关，一个仓库固然能够选多个物流公司了，
因此我想仓库应该是和多个物流公司发生关系，而邮费是物流公司要求仓库发货支付的，从这句话的描述中，你们应该能想到些什么。
邮费是物流公司的属性，仓库没有邮费的属性，仓库的邮费是物流公司的邮费报价，大概是这个样子。

可是目前据观察全部的电商，大概的样子这样基本能知足需求，并且用户在购物的那个时刻根本是不关心你仓库和物流的关系，只关心包不包邮，邮费多少。（固然有人会问使用什么物流，这是题外话，不考虑）具体支付给谁，用户确定第一认为就是支付给你了，因此能够暂时不用想那么多，邮费按照上边的设计基本能知足需求，因此不用在想那么多了，固然多想一想必定是有好处的。