一個活動該擁有哪些資訊？

就像車票一樣，需要有車次、座位、時間我們才能知道我們該搭哪台車，而活動也一樣需要這些資訊，甚至更多，畢竟使用者不希望找個資訊還需要抽絲剝繭，主辦方也不希望一整天的時間在答覆Q&A，以下我用 Table 的圖例直接呈現需要哪些欄位：

活動資料 DB Schema

• Events 活動資料主檔

  • Id 唯一識別 PK
  • Title 活動標題
  • SaleTimeStart 活動售票起始時間
  • SaleTimeEnd 活動售票結束時間
  • ProgressTimeStart 活動進行起始時間
  • ProgressTimeEnd 活動進行結束時間
  • SimpleIntro 活動簡介
  • CategoryId 活動類型 FK

• EventsCategory 活動類型

  • Id 唯一識別 PK
  • EventsCategoryName 活動類型名稱

• EventsInfo 活動詳細資料

  • Id 唯一識別 PK
  • EventsId 活動主檔Id FK
  • ApplicantLimitedQty 報名人數上限
  • EventsApplicantsQty 目前報名人數
  • PeronalSite 粉絲團/部落格等URL
  • Location 舉辦地點
  • FullIntro 完整活動介紹

• EventsImage 活動圖片檔

  • Id 唯一識別 PK
  • EventsId 活動主檔Id FK
  • ImageFilePath 圖片儲存路徑
  • ImageFileName 圖片檔名
  • ImageFileSize 圖片大小
  • UseTypeId 活動圖片類型Id FK

• EventsImageUseType 活動圖片類型

  • Id 唯一識別 PK
  • UseTypeName 圖片類型名稱

• 共同欄位

  • CreateTime 資料建立時間
  • CreateUser 資料建立者
  • UpdateTime 資料最後異動時間
  • UpdateUser 資料最後異動者

DB Schema 設計工具

這邊設計 DB Schema 的工具為 dbdiagram。
一般使用為免費，設計方式是類似寫 Code 的方式來運作（印象中 python 是不是有類似的 ORM 套件 XD），
並且可以輸出圖檔或是 SQL Server、PgSQL、MySQL 等 CreateTable 語法檔，
也可以反向上傳 SQL Server 等資料庫的語法來生成 dbdiagram 的 Code 與 DB Schema 圖檔，
可以說是相當方便阿～
推薦給大家！

本日結語

今天延續上篇的情境，將敘述中提到的重點，提煉出來設計成 DB Schema。

其實我在設計 DB Schema 時，會發現自己似乎無法一次直接設計到位，很常突然想到甚麼又加上幾個欄位，或是又生出好幾個 Table 等等的，可能是功力還太淺哈哈哈～如果各位知道提升 DB 設計功力的方向或是資源，希望能在留言處分享～感激不盡！

對了，本次系統的設計（畫面、功能等）會參考 KKTIX 與 Accupass，在此告知大家。

明天的內容會淺談 DB 的索引的基本原理與用途。

以上是今天的內容，我們明天再見！