如题“仓库单表设计”，只谈一张表。
本来想命题为“浅谈简单仓库的数据库设计”的但发现还是命题太大，
仓库设计，设计的东西太多了，库存，进库，出库，日志，盘点等等等等，非常多，而且很细，所以写完后再次修改命题，就谈一张表的设计。
所有做电商的只要有库存的概念的一定会半生有仓库的概念，像淘宝京东这样还有店铺的概念。
像店铺，这些暂时先不谈，以后我想说了在细聊。今天想谈的是简单的仓库设计，就设计一张表，仓库表单表怎么设计。
为什么想谈这个，为什么一定要谈，也是因为实在忍不住了，最近更是头疼的要命，憋屈指数到了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，可以在细化讨论，但是大概方向就是这个这样子的。
这样看，这一版的设计要比第一版高端的多，感觉这个就很不一样，特别棒，为自己点赞。哈哈
然后谈一下邮费的设计，邮费这块，我怎么想的，
邮费这东西应该是交给物流的，应该是和选的物流公司有关，一个仓库当然可以选多个物流公司了，
所以我想仓库应该是和多个物流公司发生关系，而邮费是物流公司要求仓库发货支付的，从这句话的描述中，大家应该能想到些什么。
邮费是物流公司的属性，仓库没有邮费的属性，仓库的邮费是物流公司的邮费报价，大概是这个样子。
但是目前据观察所有的电商，大概的样子这样基本能满足需求，而且用户在购物的那个时刻根本是不关心你仓库和物流的关系，只关心包不包邮，邮费多少。（当然有人会问使用什么物流，这是题外话，不考虑）
具体支付给谁，用户肯定第一认为就是支付给你了，所以可以暂时不用想那么多，邮费按照上边的设计基本能满足需求，所以不用在想那么多了，当然多想想一定是有好处的。