最後的兩回中研究別人怎麼設計資料庫。
這回主要探討電商，因為沒有現成的範例，所以只好去找一個大略可以講的範例。
分析
因為電商，所以最主要是販售物品為主，會有庫存、商品、結帳，讓顧客如何順利地購買產品、保留過往資料以供糾紛調查是最重要的。
以下是我找到的電商模擬資料表:
從資料表上分析
先從user來說，首先要建立的就是顧客資料。
於是有了user、user_address、user_payment三張表。
而關係到能否正常運送、付款，所以把關鍵功能拿出來開表也是很正常的。
為了避免欄位過多，把不相干的項目拉出去就是資料庫正規化。
不斷比較各個欄位與該列表的主鍵關係，把表拆出，即2NF、3NF。
再來是product，產品。
因此有了product_category、product_inventory、discount三張表。
產品的分類、庫存、折扣，而其中庫存最重要，因為它關係到能否正常賣出東西。
雖然我不知道為什麼不直接把product_inventory的外來鍵設定成product的主鍵，這樣能更直覺的去Mapping。總之，多開這一張庫存表可以知道販售的情況、庫存異動情況。在價格變動上，想追蹤也是可以這麼做的。
而discount表，則是拉出來，獨立處理這商品套用的折扣，有個active，可以啟用、關閉。我覺得這張折扣表上可以加一個修正價錢，等於有一段時間打折能直接套用這折扣價，照原本設計是用百分比去折扣。
我覺得這商品是最難的規劃，會有多種不同價格，怎麼記錄他異動等等。
再來是購物車shopping_session、cart_item。
因為我們可能會換電腦操作，所以不能放在Cookie，會需要購物車幫我們紀錄要買哪些資料。
在這cart_item裡面就是不斷添加產品product，可能有N個產品，之後這N個產品都算在同一個shopping_session上。
這段我自己覺得只要cart_item就好，就是購物車裡放哪些東西，因為只是用來暫存用的。
結帳完成訂單order_details、order_items、payment_details。
在最後流程就是使用者要能夠結帳、產生訂單。
把cart_item的資料都拿出來，放到order_items，之後點下結帳時，用程式的”交易”的寫法，去檢查能正常扣除庫存，就建立這筆訂單。
此外，訂單建立就是付款了，只要照著付款流程付完款，在更新payment_details即可。
而order_details則是記錄這筆訂單總金額、備註等等。
如果被刪除了，是否要自動把庫存加回去就看個人需求，總之能做到。
如果怕有糾紛問題就是多存一份沒關聯的字串資料。把當時結帳的商品名稱、款項都寫明，已備不時之需使用。
此外，商品那些都做成軟刪除，因為未來可能會需要關聯，所以能看到有deleted_at欄位。
deleted_at、modified_at、created_at在資料庫的表建議都建立，以供人工好追蹤。
然後，發現好像大多數資料表設計如type類型都設定成varchar，應該在拉出去一層關聯會比較好，往後類型被改會比較容易更新，只取代一個跟取代N個的差別。
從型別上分析
時間它是用timestamp，但如果SQL server用datetime2會更好。
商品的價格上price用decimal，跟我前面幾回探討過的型別有關，就是選沒有誤差精確數值。
在id上是int，但其實也可以用bigint如wordpress就是用bigint。
文字用varchar。
總結
從這個資料庫來看，已能滿足大多的需求，我覺得關鍵在這系統主要想幹嘛，在把那部份特別補強設計架構，就八九不離時了。
主要的功能表能設計的穩固，後面要擴建就能容易些。
此外，我覺得還能再加上個折價券表，可以套用在最後的結帳上。