資料庫欄位設計與正規化

我也沒想到，工作十幾年之後，居然還要寫這樣的題目。資料庫正規化設計，在21世紀的今天，應該早就是攻城獅(工程師)耳熟能詳的必備項目，沒想到還有人用20世紀的思維在設計，因此稍稍抒發小弟我不滿的情緒。
首先，一般人設計資料表時，應該做到第三正規化，請參考微軟的資料庫正規化基本概念，若想知道更多正規化細節可以參考WiKi的資料庫正規化。

那為什麼會產生反正規化的設計呢?最常見的情況是Data Warehouse，為了要把所需的資料都放在同一個table不要做太多層的Join/Sub Query以增快查詢速度。

現在，要來提30年前的可怕反正規化設計方式，早期在VAX時代，敝公司的人事系統，把職級代碼與職稱代碼放在同一個table，超過50為界限。這在查詢時真是宇宙無敵麻煩，沒想到MIS先生在改版時還follow這設計...

另一個20年前的反正規化設計，為了寫程式時的方便不要寫複雜的SQL查詢與Join，把多筆資料放在同一個欄位，用逗號分隔。舉例來說，有人訂了雞腿飯(代碼1)，欄位值就是1，若再訂了排骨飯(代碼2)，欄位值變成『1,2』。在介面上呈現時，由他的程式去判斷有幾筆訂單。

這時就有人會說，這樣很好呀！省空間又快。鄉民程序員醒醒吧，現在最流行什麼?
大平台大數據呀！想一想，把這種資料丟到BI工具時會怎麼樣?沒有辦法自動Join，所以需要手動去拆解這樣的反正規化欄位，光是BI的Function就會寫到想砍人，訂便當的例子可能要DBA去展開訂單資料另外建table才能分析...

所以，孩子，普通的CRUD系統就乖乖地導守古人的智慧做第三正規化吧！