跳到主要內容

資料庫欄位設計與正規化

我也沒想到,工作十幾年之後,居然還要寫這樣的題目。資料庫正規化設計,在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系統就乖乖地導守古人的智慧做第三正規化吧!

留言

匿名表示…
你們公司都找原始人當員工嗎?

這個網誌中的熱門文章

自然人憑證讀卡機驅動程式

鳥毅用的是第一代的自然人憑證讀卡機,EZ100PU(後來有同事買EZmini可以讀SIM卡似乎更好),每年報稅時用一次。 本來只是要申請些政府業務,一時之間找不到光碟,沒想到在 驅動程式下載 居然看到Linux和Mac的驅動程式,剩下的就是政府單位的網頁和程式應該改版了吧!!!

用ZedGraph畫統計圖

Update: 沒想到這篇居然變成Google搜尋ZedGraph第一篇中文網頁,不過還是誠心建議用Windows上的C#先看一下 免費的圖表元件:Microsoft Chart Controls ,除非你非得用.Net 2.0(Windows 2000)或是用 Mono 。 BTW,我並不想成為微軟MVP,所以本Blog並不是有問必答的喲^_^ 才剛貼完上一篇,馬上就有位朋友丟過來一個LGPL Open Source元件的網址: ZedGraph 。 參考: A flexible charting library for .NET