來都來了，坐一下再走🍵
隨便看看，這裡是我整理的一些技術筆記，看到覺得有用的就拿去用吧。
系列文章
查看全部最新文章
查看全部資料庫
資料庫架構設計入門：用 PRIMARY KEY 識別每一筆資料
前面我們介紹了第二正規化、第三正規化，還有第一正規化的後半。
現在終於要進入第一正規化的前半，也就是整個正規化形式的最開頭。
第一正規化的前半告訴我們：表單要有一個欄位是主鍵（Primary Key）...
2026年1月9日
資料庫
資料庫架構設計入門：用 NOT NULL 限制確保欄位必填
上一篇文章介紹了 NULL，讓我們可以在欄位中表示「沒有資料」。
但反過來想：有些欄位是不是不應該允許空值？
例如會員的姓名。一個會員一定要有姓名吧？如果連姓名都沒有，這個會員資料就不完整了。
這篇文...
2026年1月9日
資料庫
資料庫架構設計入門：用 NULL 表示沒有資料
前面的文章我們討論關係類型時，都在問「最多」：
一個會員最多可以有幾支電話？
一支電話最多可以被幾個會員持有？
但有沒有想過：最少呢？可不可以完全沒有？
例如一個會員可不可以完全沒有電話？一個人可不可...
2026年1月9日
資料庫
資料庫架構設計入門：用 UNIQUE 限制確保資料不重複
上一篇文章介紹了一對一、一對多、多對多三種關係類型，也學會了怎麼設計表單來記錄這些關係。
但有個問題：我們怎麼確保這些關係是正確的？
例如會員和電話是「一對多」的關係，一支電話只能被一個會員持有。但如...
2026年1月8日
資料庫
資料庫架構設計入門：一對一、一對多、多對多關係
上一篇文章介紹了第一正規化形式，我們知道「一個會員有多支電話」這種情況要拆表單。
但這種「一個對應到多個」的關係，在資料庫設計中有專門的名稱，叫做「一對多關係」。
除了一對多，還有「一對一」和「多對多...
2026年1月8日
資料庫
資料庫架構設計入門：用第一正規化處理一對多關係
前面的文章介紹了第二正規化和第三正規化，都是從「欄位之間的相依關係」來決定要不要拆表單、刪欄位。
這篇文章要介紹的第一正規化形式，角度不太一樣——我們要從「資料列」的層級來看，有沒有需要調整的地方。...
2026年1月7日