很多的程式設計師,總是會犯這種錯誤..導致後來系統越來越爛..
越來越爛,基本上都是這幾個原則沒有把握住.
第一個大忌,懶, 不想新增欄位, 使用已有欄位存放新的資料.
舉個例子, 客戶姓名, 客戶代號,客戶ID, 可能有的系統設計的時候,只有客戶姓名和客戶ID, 沒有客戶代號. 然後某一天在跟其它系統對接的時候發現, 咦, 需要存放客戶代號.對方發過來的是客戶代號..沒有客戶ID… 老闆催的又急,急著出結果.. 腦袋一熱, 不管了. 先上了再說… 先把客戶發過來的客戶代號放到客戶ID裡吧.. 反正能執行起來, 系統跑起來再說….

第一個大忌,一個欄位內,存放兩種意義的資料, 違反了 資料庫設計的 第一正規化 ..
舉個例子, 醫院系統裡面, 病人的編號. 這個欄位經常會存, 病人的住院號, 有的又存醫保代號,有的又存身份證號, 還有的存電話… 雖然都可以當作編號…後期的資料分析怎麼做?
而違反這個規則的, 往往都是後期, 後期在維護的時候腦袋一熱就存進去了… nmd. 我看到這樣的資料只想殺人….

第三個大忌, 欄位名跟實際存放的內容不一致.
這是一個非常大的隱患. 今天很清楚, 這個欄位存放的是什麼東西… 過些日子, 就不知道了. 按照欄位意思來理解, 然後把其它東西也存進來了. .. 結果就開始亂糟糟了.

第四個大忌, 缺東少西,
一個表看上去, 30+個欄位.主要的幾個欄位存的資料都不全. 不是少這個就是少那個, 應該要存的資料. 偏偏有的模組會存, 有的模組又不存. 讓後來人,怎麼去查詢呢? 是該相信還是不該相信呢?這種資料表一般是那種很多很多年的老系統經過很多人的修改越來越爛的系統會存在這種情況.

第五個大忌, 死搬教條式的, 向資料庫的設計正規化靠攏. 導致資料越來越少,系統越來越複雜..
資料庫設計的3大正規化, 其中有一條, 被非常多的程式設計師堅持著. 而這種堅持, 在今天看來, 完全就是死腦筋… 舉個例子, a->b->c->d 4個表, 資料建立順序分別是, 現有a的資料,再依次建立b的,c的,和d的.
那麼按照資料庫設計正規化, b裡面有a的主鍵, c裡面有b的主鍵, d裡面有c的主鍵….. 如果僅僅是這樣.以後的程式設計師要累死的.
合理的資料庫設計, 一定是 a的欄位b裡面都有, b的欄位c裡面都有, c的欄位d裡面都有.
資料應該是越來越多的, 怎麼能越來越少了呢? 甚至是要流水似的反查回去呢?

一個優美的資料表是一切系統的良好基石, 表都設計不好的,程式設計師. 能搞出什麼像樣的系統?? 搞來搞去搞自己…

我寫資料庫相關類的系統, 10多年了. 可以說,各種各樣的爛系統都見過… 時間越久的系統確實爛的越嚴重… 基本上都是上面的這幾個問題…

一個合格的優美的資料庫表結構, 應該是,一張資料流水圖.

枝葉上的應該是基礎資訊表.

而主幹則是業務資訊主表.

這裡個主幹的粗壯並不單單是資料量的增多, 欄位也應該是越來越多,越來越齊全的.
資訊流著流著就沒了. 這樣的系統活不久. 早晚成 “死海”

在這裡我甚至在想, 我們目前的關係型資料庫還有一大可以改進的點.
每次我們查詢資料都要 left join . 做表間關聯. 是不是可以把這種表間關係, 先維護設計好. 固定在資料庫設計之中. 而查詢的時候自動根據這個關係解析, 查詢出相應的結果.. 這樣我們的資料庫查詢語句會更簡單. 插入和更新也會更簡單.