談一談商品編碼的問題
如題：今天談一談商品編碼的問題，我們不是完全從物流和商品本身的角度去談商品該怎麽編碼才符合國際標準，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，什麽都行。
談一談商品編碼的問題