#4 自己設計的 database schema 是不是好的呢 ?

 前面的幾篇文章都講了些較基礎也較偏向課本的內容,在這篇裡面我們來談談比較實務的題目,那就是你怎麼知道你設計的 database schema 是不是好的?

如果你的工作是軟體專案的成員,這題目一定早就會在你心裡了.市面上的軟體專案有很大的部份都需要資料庫,用來儲存企業內所需的資料,而幾乎大部份市面上的專案所需要的資料庫都是關聯式資料模型 (Relational Database),因此 database schema 的設計便是整個專案內容的設計中其中一個項目,也就是你要了解什麼是 ERM (Entity Relationship Model).也許你之前念過一些課本的內容或是上過一些課,但若沒有真正自己參與設計的話,有時你心裡一定會覺得我這樣的設計是不是好的呢?

這篇文章的內容不是要教你如何設計 database schema,其實你只要遵循著課本裡面所教你的原則來設計,設計出來的結果就不會有太意外的錯誤.比如,你知道什麼是 Entity 和 Relationship,相信你一定知道如何把 Entity 轉成資料庫中的表格以及如何用表格和欄位來實現 Relationship.我的看法是只要你正確地遵守了這些原則並且嚴格確保了正規化 (Normalization) 的存在 (一般業界的軟體專案所做的正規化至少要到 3rd normal form),設計出來的 database schema 應該都可以有八十分.以上是從資料庫的角度來看 schema 的設計,而接下來的二十分,我們就要從程式與效能的角度來思考.

在專案一開始的時候,很有可能資料庫的設計已經完成了,但是程式架構尚未完成,所以 database schema 的設計是否適當,這很難決定,畢竟存取資料的不是人,而是工程師們寫的程式,而資料存取會不會快,那就要看工程師們是怎麼寫程式了.所以你會發現,一個好的 database schema 很難在一開始就完成,除非那是個很簡單又單純的專案.

通常來說,你所設計的 database schema 能不能是個很好的設計,最大的影響是程式讀取的快慢,我們暫不考慮產品與硬體的影響,通常來說,當你的 schema 裡有很多的表格,程式在讀取資料時常常需要 join 很多的表格,這將會大大影響效能,因為 table join 雖然在關聯式資料庫中是一個很平常的事情,但也是一項成本高的運算.因此,你可以思考改進的第一個方向就是如何在不違背 ERM 和 Normalization 的原則之下將會被做 table join 的資料庫表格的數量降到最低.未來的內容,我們再來討論為何 table join 是一個成本高的運算.

第二個可以參考的方向是 Index,不論是做 table join 還是單純在一個表格上尋找資料,如果事先做好了 Index ,它將會幫助資料庫引擎能夠更快速的找到資料,因此就能更快速地完成 table join 或其他的資料存取動作.我們也會在未來的內容裡來說明 Index 如何幫上忙.

最後還有一點 De-normalization (反正規化).相信大家在課本上或實務上都會聽過這個名詞,據說它的做法能夠提升效能,但在電腦的世界裡是沒有白吃的午餐.以我個人的經驗而言,其實我不是很喜歡這東西,重點不是簡不簡單或難不難,而是它會改變了一些基本的思考而造成系統後續維護的問題. 我舉一個很簡單的例子,比如你有一個資料庫系統,裡面有一個表格,這個表格很簡單,只有兩個欄位,一個是 user id,另一個是 function id,如下所示:

User IDFunction ID
User AFunc A
User AFunc B
User BFunc A

想像這是一個很長的表格,它記錄了那些使用者可以使用那些功能.現在的情況是大部份的使用者都可以使用所有的功能,所以你可以想像使用者多功能多時,這表格有很多的筆數.你的老闆說這表格實在太長了,管理起來真麻煩,於是他想要弄一個東西,也就是如果某個使用者可以使用全部的功能的話,那麼就用 * 來代表所有的功能.

User IDFunction ID
User AFunc A
User AFunc B
User BFunc A
User C*

如上面表格所示,這代表 User C 可以使用所有的功能,這就是一種 De-normalization 的結果,如果你經驗不多,可能會一時覺得好像很方便,因為表格的資料筆數可以減少,同時要讀取 User C 的功能數量時也很變快,因為只有一筆資料.但你想想,你願意配合做這樣的改變嗎 ? 如果你是軟體工程師,你可能會不太高興,因為你會發現必須要寫一些 "特別" 的程式碼來處理 *.更慘的是,如果這些都是前人的工作,沒人告訴你什麼是 *,你可能要花點時間才能搞懂它的目的.

我在這裡要說的重點是並非所有的 De-normalization 都是好的,這樣的做法的確對資料庫引擎是有益的,因為資料讀取的成本變少了,但卻在程式邏輯上增加了更多的程式碼來處理.這樣一來一回的情況下很難評估是不是真的有好處.以整個系統的角度來看,除非你真的感受到很多的好處,不然就無需 De-normalization 了.

Share: