資料庫正規化摘要

April 21, 2024

這篇文章是 Prograss Bar 網站「不是工程師」系列內,「資料庫正規化」系列文章的摘要,推薦在設計資料表 (和面試) 時閱讀,確保資料庫的查詢效能和編輯的方便性。文末還有另一篇對正規化文章的摘要。

「資料庫正規化」文章摘要

第一正規化的關鍵:資料表內沒有重複的紀錄,可以透過設定主鍵 (Primary Key, PK) 達成,通常是建立 ID 欄位。

如果能確保資料表裡有唯一的紀錄,就可以明確的查詢到特定紀錄,不用擔心會新增/查詢到重覆資料的問題!

「不是工程師」關聯式資料庫正規化是什麼? 先從第一正規化(1NF)開始吧!(database normalization, Primary Key - PK)

第二正規化的關鍵:將容易重複資料、只和表格部分相關的欄位,拆分成不同表格,建立外來鍵 (Foreign Key),和其它表格產生關連。

資料表有很多重複欄位時,會導致資料量過大,占用很多儲存空間,並花費很多時間查詢!

「不是工程師」外鍵Foreign key(FK)是什麼?從第二正規化(2NF)去除冗余資料談起吧!(database normalization)

第三正規化的關鍵:如果可以從其它欄位計算或推斷出來,就不要設立一個欄位去紀錄。

紀錄要計算的欄位,就要考慮到編輯資料後,有沒有一同更新的問題,否則會有計算結果不正常的問題。

「不是工程師」可以邏輯推斷出來就不要多加欄位?淺談資料庫第三正規化(3NF)

欄位共用的思考

資料庫正規化以後,如果要修改資料,很容易遇到其它欄位沒有一起更新的問題。

設計時就要問自己,哪些資料要留下歷史紀錄,才不會遇到更新資料後,其它欄位產生落差的問題;或是另外寫 SQL 語法定期 / 觸發一同更新其它欄位的資料。

資料庫設計之共用/不共用欄位 - 《Chris 技術筆記》

效能的影響

有時在設計資料表,可能會考量到多個資料表 Join 的影響,違反第二正規化,將資料放在同一張資料表內;也有可能會因為常常取得計算結果,將結果記錄在資料表內,然而這也違反第三正規化。

對於以上效能的案例,需要在效能和正規化設計的優點間做出取捨。