許多開發者誤以為資料庫設計只是「建庫、建表、加欄位」，實則是一套完整的工程流程：**需求分析 → 邏輯設計 → 物理設計 → 維護優化**，每階段側重點不同。
良好設計可減少資料冗余、避免操作異常、支援有限儲存與高效存取。經驗教訓：畢業設計因前期設計不佳，後期查詢極度困難，寫再多 SQL 也難彌補架構缺陷。
核心三要素：
關鍵概念：
| 術語 | 對應關係 |
|---|---|
| 關系 | 一張資料表 |
| 實體 | 管理物件 |
| 元組 | 表的一行資料 |
| 屬性 | 表的一欄 |
| 主關鍵字 | 唯一標識實體的屬性 |
| 候選關鍵字 | 需多屬性組合標識 |
實體與屬性識別：
學生: {學號, 姓名, 性別, 聯系方式, 宿舍號}
宿管: {宿管ID, 姓名, 性別, 聯系方式}
物業: {物業ID, 姓名, 性別, 聯系方式}
後勤: {後勤ID, 姓名, 性別, 聯系方式}
住宿信息: {id, 姓名, 學號, 性別, 宿舍號, 專業, 班級, 聯系方式}
宿舍: {宿舍ID, 樓棟號, 宿舍號}
物品報修: {id, 物品名稱, 損壞情況, 報修人, 聯系方式, 宿舍號, 報修時間, 緊急程度, 是否處理}
用水信息: {id, 宿舍號, 用水量, 本月剩余水量, 剩余金額, 欠費狀態}
用電信息: {id, 宿舍號, 用電量, 本月剩余電量, 剩余金額, 欠費狀態}E-R 圖關聯說明（因原圖過大僅展示部分）：
<m> = 非空，<pi> = 主鍵，<ci> = 候選鍵| 類型 | 說明 | 例子 |
|---|---|---|
| 一對多 (1:N) | 一方對應多方 | 班級 1:N 學生 |
| 多對一 (N:1) | 多方對應一方 | 學生 N:1 班級 |
| 多對多 (M:N) | 雙向多對應 | 老師 M:N 學生（需中間表） |
| 一對一 (1:1) | 雙向唯一對應 | 用戶 1:1 用戶詳情 |
| 繼承 | 子實體繼承父實體屬性 | 學生/老師 繼承 人 |
| 依賴 | 弱實體依賴強實體存在 | 門窗 依賴 房子 |
| 特性 | CHAR(n) | VARCHAR(n) |
|---|---|---|
| 儲存方式 | 固定長度，不足右補空格 | 變長，實際長度+1~2 位元組長度前綴 |
| 最大長度 | 255 字元 | 65,535 位元組（共享行大小限制） |
| 空間效率 | 定長資料較優 | 變長資料節省空間 |
| 更新效能 | 無行遷移風險 | 長度增長可能觸發 行遷移 |
| 索引效能 | 固定偏移量，略快 | 需讀取長度前綴 |
行遷移：Oracle 定義 - 行初始能放入 block，更新導致變長超出 block 剩餘空間，Oracle 將行遷移至新 block，保留原指標指向新位置，ROWID 不變。MySQL InnoDB 類似機制稱為「頁分裂」。
選型建議：
- 定長、高頻更新、極短欄位（如性別、狀態、ISO 代碼）→ CHAR
- 其餘變長文本 → VARCHAR
- 大文本 → TEXT/LONGTEXT
- 大數據量場景才需深度權衡，中小專案 VARCHAR 通吃無壓力
包含索引優化、查詢重寫、分區分表、讀寫分離、監控告警等，專業 DBA 領域，開發者了解基礎即可。
總結：資料庫設計是系統穩定性基石，投入前期設計成本遠低於後期重構代價。建立團隊設計規範、評審機制、版本化變更流程，才能避免「為了趕工期埋下技術債」。
