1. 資料庫模型

2. 現實需求
 B2B,B2C,C2C,ERP,CRM等等系統，都涉及彈性資料庫
架構問題，就是說夠彈性的資料庫可以開發所有系統。
 資料庫的設計錯誤來自於，系統範圍的評估錯誤。
例如：今天只開發購物車平台，而資料庫只設計到購
物車平台的需求。爾後要擴增系統就變得遙不可及。
 如何設計出彈性資料庫，多參考Open Source系統的
資料庫設計(Open Cart, Joomla, etc..)。

3. 型態一 平台與店家
 平台如何配發不同的系統給各店家，同時又能管理?

4. 型態一 常見錯誤
 Company 資料表設計
 1.流水號當做店家編號
流水號僅能讓系統辨識，不可用於一般資料的顯示
 2.Company資料表與帳號、密碼欄位一起設計。
公司屬於法人本身不因與自然人混為一談。公司董事
長可能換人，故是Member資料表中設計誰加入這家
公司。
3.Company中設計子系統

5. 型態一 常見錯誤
 3.Company中設計子系統
由於公司還包含會計、業務、資訊等單位，子系統的
配發是不同的，應於權限資料表中設計，該公司的某
單位權限有哪些子系統。

6. 型態一 實際設計
 看得出會員所屬的公司、權限及子系統
(comp_moudel)

7. 型態二 KeyValue
 KeyValue的資料庫設計應用於非常態性事件，例如：
產品分類、倉儲區位。
 KeyValue的好處
1.非常態事件創立資料表是很耗費資源的，省下資料表
的空間。
2.彈性的結構可以隨時擴增需求，例如：產品規格、尺
寸、Size。

8. 型態二 實際設計
 多家公司的類別僅需一張資料表的資源

9. 多對多關聯 (many-tomany)
 書籍資訊、活動報名是典型的多對多關連，這種資料庫的設計無
法直接滿足需求。需仰賴資料儲存的格式。
 例如：作者編號一筆資料僅能存一個編號(10194025)
但如果儲存為：10194025|10194000，就可以完全解決多對多的
問題，但符號的儲存並非最好的方式。可參考用序列化

10. 交易設計
 買賣行為、進出退貨、製成、領料的交易設計都包含
主子單的概念，即是兩張資料表中有直接相關性

11. 交易設計
 更明確的說明，第一區的紅色部分為主交易單，記錄
整筆交易的資訊，但第二區紅色部分只記錄品項相關
的事情。