谈一谈商品编码的问题
如题：今天谈一谈商品编码的问题，我们不是完全从物流和商品本身的角度去谈商品该怎么编码才符合国际标准，EAN，UPC啥啥啥怎么样的。
我们从计算机程序设计，电商，数据库存储的角度看一看商品编码，首先商品有哪些编码，然后这些编码和商品的关系，在然后这些编码该怎么使用。
要从电商的角度了解商品，马上想到的可能是淘宝，天猫，京东，亚马逊等他们的商品是怎么样子，是怎么存储的。
这些这么成熟的电商完全可以参考和借鉴。
关于商品这个话题还是太大，因为商品本身设计的东西太多了，不同活动先不同的价格，多规格商品，不同的计量单位，多图片展示该怎么存储等等。
每一个点都值得单独拿出来仔细讨论和思考，所以商品这个话题还是太大了，我们就定位一个小的问题编码问题，其他的问题我会在之后每一个都会细细谈到。
那么关于编码，我网上搜到的有sku_code、spu_code、barcode、serial_number等，还有仓库给条的tag标签上也有编码。
那么这些编码各自代表什么含义，表示商品的什么属性和商品的对应关系，该怎么使用，具体到程序设计上，数据库该怎么设计，怎么存储。
下边我们就一一把每个名词给予讲解，这些讲解不是从物流，商品专业角度讲解的，但也和那些专业上的差的不是很远，所以也有助于理解。
这些解释是从程序开发，设计角度讲解，如果你是程序员，设计师，那么你应该好好读一下有些了解。
一贯的作风，为什么要谈这个问题，为什么要谈商品编码，在做和ERP对接的时候，让我带一个没有任何经验的产品妹妹，和没有对接经验的技术哥哥。
新人肯定需要人带的，我当时脾气不好，然后我们工期还特别的紧张，特别的紧张更加弄的我脾气暴躁，焦虑。我首先得承认自己的错误，脾气不好。
然后我们在心平静气的来谈一谈，对接的故事。
首先对接，我们商城和ERP对接肯定需要有商品上唯一上标示能标示两边推送，对接的是同一个东西。
在我们这个小team里，我对于这个小产品妹妹和技术哥哥算是一个天降leader，我还算不上一个完全的leader，就是这个意思吧。
就是他们对我不了解，我也对他们不是很了解，而且在我对ERP对接这项目也不了解，就这么着，说我们要一个月对接ERP项目。
然后对接技术细节呢，我们的技术哥哥说要用我们的gd_id来对接ERP，我当时就晕了，痛苦不已。
我在想我们是用我们自己数据库的自定序列ID来对接别人程序，这个是一个什么想法。
然后我仔细研究了我们自己的数据库和ERP系统，还好，还好，还好我们还有一个gsn这样的东西，首先说明gsn这个东西的值完全等同于sku_code。
大家先听我把故事讲完，咱们在细谈什么是sku_code这些，有这么离奇和好玩的故事，为什么一定要急着知道各种编码，听故事岂不是很好。
然后由于程序和设计这边都是我自己来弄，说是让我带他们，其实我私下自私和不负责的想法是让他们看着我开发，
我有了这样的想法，加上我当时我们工期紧，我压力大，我能不生气。我这样的想法是不是太臭屁了。
所以我最后固执的坚持了自己的想法，就是我要自己做，我自己重新建表，我用自己强大坚持和固执的想法，在有些地方完全不听任何人的意见和建议。
最后我终于让他们知道了SKU，SPU，barcode这些概念。
最后程序开发出来，终于能让他们自己，从自己口中经常说SKU，SPU了，终于是让他们认同这些。
这期间好玩的事情是产品妹妹纠结条形码barcode纠结了3天，
最后我非常生气的告诉她如果我们不使用什么条形码，如果条形码在我们系统里没有多少意义和使用价值那我们就不做barcode了，
然后我们的采购还说一个产品可能有多个条形码，我真是醉了，最后我固执的认为一个商品就只有一个条码，如果有多个以后再说，
我们开发测试上线真的没有多少时间，纠结这个纠结3天，因为我生气，我被老大批评一顿。
还有好玩的事情，我们和别人对接，比如仓库，比如ERP，有些东西，我们不明白，需要请教ERP或仓库的人，
我们的采购小哥再请教别人时，我听到的对话都是仓库那边的回答和讲解只有；“是，嗯，是，嗯”，最后问题没解决。
然后我还要自己亲自在问一遍，让对方讲话，让对方说清楚。
更加搞笑的事情是，我们有个QQ群，突然有一天我们的产品妹妹跟我说，QQ群里跟咱们对接ERP那边一个哥哥退群了，好搞笑啊。
我感觉没有什么搞笑的，可能那哥们忍受不了我们的折磨，不愿意受打扰吧。
我们时间紧，任务重我们要加班，然后我们也拉着ERP的人一起加班，这本来是合情合理大家都互相理解。
后来ERP那边来了个牛人之后我们跟ERP对接算是比较顺畅的。
最后团队磕磕绊绊终于把开发搞定，到最后导入数据是，产品妹妹的一个好心修改ERP的默认设置，导致我们加班了大半夜。
也因为开发测试不全面数据导入一半时发现导入的产品全部下架，当时我吓的满身冒冷汗，我们的商城商品全下架了，吓死了。
还好导入的数据不多及时发现，停止了重新，修改程序，在测试再上线，最终也算是圆满的完成任务。
这就是我们对接的故事，虽然大家都没有多少经验，但不能说大家不努力，我们产品妹妹还是的挺认真负责的这确实值得表扬。
这也是为什么一定要谈商品编码的问题的原因。
那么什么是SKU，是什么是SPU。
我个人理解要理解这两个名词，还得要结合计量单位，这样子更加全面。
我忘记了从哪里查到的例子了，我感觉那个例子说的非常好，例子大概是这样子。
比如说烟这个商品，那么烟有中华烟，云烟，钻石等等，中华烟又分软盒，硬盒，钻石又分红钻，蓝钻，黄钻，QQ钻等等，
QQ钻，是我假设的，估计且这么认为吧，我不吸烟对烟了解不多。
那么在商城，特别上电商，看到的商品列表上一定只是展示了中华，钻石，云烟，在列表上一般不会在展示软盒中华，红色钻石烟。
只有在详细页面点开中华时会看到有软盒的硬盒的让你选。
SKU，SPU具体的名称解释咱们不说了，百度，谷歌一堆一堆的，我解释也不一定完全对，但我说的一定能帮助你理解。
到这里那么就可以这么看SPU和SKU了，列表上看到中华，钻石这一种类的集合算是SPU，
而具体的像软盒中华，红色钻石，那个非常具体的就是SKU了，这里需要明确和多想想思考的地方就是商城卖的东西一般一定是一个SKU。
那么刚才我说过了个人感觉加上计量单位才算更加全面，
为什么这么说，网上的例子也是非常棒的，还是烟这个例子。我们都知道烟的计量单位一箱子有20条，一条有10盒，一盒有20根。
不同的人或者销售对烟的计量单位是不一样的。
比如说，生产烟的烟厂，它卖烟一定是一箱一箱的卖，那么对于它来说它的SKU应就是一整箱。
而小商店，小商城呢，一定是一条或一盒一盒的卖，那么这个SKU的计算应是条或者盒才对。
而在细化到大家聚餐喝酒，吸烟，你递我一支，我递你一支，这时的SKU计算是支才对。
所以从程序的角度理解这些感觉是加上计量单位才完整。
不知道从真正的仓储，物流上怎么理解SKU和SPU，希望懂的大神不吝赐教，非常感谢。
所以总结就是SKU是商城卖出货物的不能分割最小计量单位，包含了价格，颜色，尺寸，包装，等等的规格。
不同的规格就是不同的SKU，黑色和白色，软盒和硬盒就是不同的SKU，而SPU是一组可以抽象的SKU的组合名称。
再有就是商品的条码barcode，我感觉认为一个SKU，应该是只有一个条形码的就像咱们买的矿泉水，纸笔，手机，等一定都有自己的一个条形码。
但是我们采购的兄弟说一个东西是可以有不同的条码的，是可以重新贴条码的，这东西我就很无奈，那就算是可以有吧，这在数据库设计时也有办法解决。
最后还有就是我在故事里讲的gsn，和我最开始提到的serial_number，这个是什么东西，通俗讲就是序列号，
我查了网上的一些资料，感觉在买商品的时候很少提及序列号这东西，序列号是什么，我理解序列号就是商品的身份证。
无论商品到哪里怎么变幻按着序列号是变的且是唯一的。
那我们故事中的gsn完全不是序列号的意思，是的gsn在我接手之前，这个概念非常之弱化，大家竟然都没人知道这个gsn是个什么东西，就知道这是我们的一个序列号。
实际上这不是序列号，是我们的SKU，这是咱们的商城同事们做了一年的商城后，我给他们明确的概念。
在合作不算愉快磕磕绊绊的团队中，我不知道是因为我生气他们恨我，怕我，
还是说我让他们了解了，更加清楚了看清了SKU，SPU，barcode，序列号，包括对接，ERP仓库，这些东西感谢我。
关于说商品编码的这块数据库设计就是一个SPU先有多个SKU，一个SKU下有一个或多个条码，有一个序列号。
大概就是这个样子：
SPU(
int id pk,
string code,
string name,
)
SKU(
int id pk,
int spu_id,
string spu_code,
string sku_code,
string sku_name,
string serial_number,
string unit,
string current_barcode,
timestamp update_time
)
barcode_history(
int id pk,
int sku_id,
string sku_code,
string barcode,
timestamp create_time
)
谈这些一定是要谈商品的设计的，而关于商品这块的数据设计，由于设计到多规格属性。我对现有的设计很不满意。
我自己也设计了一版，对比我们现在设计是有天壤之别的，但是我也是感觉还是不满意，这个对多规格的设计还是很头疼的。
不过，我会陆续把这个产品这块的整体设计和思路全部发出来。
最后最后，非常欢迎大家评论和讨论，whatever，什么都行。
