資料庫模型

926 views

Published on

Published in: Education
  • Be the first to comment

  • Be the first to like this

資料庫模型

  1. 1. 資料庫模型
  2. 2. 現實需求  B2B,B2C,C2C,ERP,CRM等等系統,都涉及彈性資料庫 架構問題,就是說夠彈性的資料庫可以開發所有系統。  資料庫的設計錯誤來自於,系統範圍的評估錯誤。 例如:今天只開發購物車平台,而資料庫只設計到購 物車平台的需求。爾後要擴增系統就變得遙不可及。  如何設計出彈性資料庫,多參考Open Source系統的 資料庫設計(Open Cart, Joomla, etc..)。
  3. 3. 型態一 平台與店家  平台如何配發不同的系統給各店家,同時又能管理?
  4. 4. 型態一 常見錯誤  Company 資料表設計  1.流水號當做店家編號 流水號僅能讓系統辨識,不可用於一般資料的顯示  2.Company資料表與帳號、密碼欄位一起設計。 公司屬於法人本身不因與自然人混為一談。公司董事 長可能換人,故是Member資料表中設計誰加入這家 公司。 3.Company中設計子系統
  5. 5. 型態一 常見錯誤  3.Company中設計子系統 由於公司還包含會計、業務、資訊等單位,子系統的 配發是不同的,應於權限資料表中設計,該公司的某 單位權限有哪些子系統。
  6. 6. 型態一 實際設計  看得出會員所屬的公司、權限及子系統 (comp_moudel)
  7. 7. 型態二 KeyValue  KeyValue的資料庫設計應用於非常態性事件,例如: 產品分類、倉儲區位。  KeyValue的好處 1.非常態事件創立資料表是很耗費資源的,省下資料表 的空間。 2.彈性的結構可以隨時擴增需求,例如:產品規格、尺 寸、Size。
  8. 8. 型態二 實際設計  多家公司的類別僅需一張資料表的資源
  9. 9. 多對多關聯 (many-tomany)  書籍資訊、活動報名是典型的多對多關連,這種資料庫的設計無 法直接滿足需求。需仰賴資料儲存的格式。  例如:作者編號一筆資料僅能存一個編號(10194025) 但如果儲存為:10194025|10194000,就可以完全解決多對多的 問題,但符號的儲存並非最好的方式。可參考用序列化
  10. 10. 交易設計  買賣行為、進出退貨、製成、領料的交易設計都包含 主子單的概念,即是兩張資料表中有直接相關性
  11. 11. 交易設計  更明確的說明,第一區的紅色部分為主交易單,記錄 整筆交易的資訊,但第二區紅色部分只記錄品項相關 的事情。

×