11 個重要的數據庫設計規則

簡介：在您開始閱讀這篇文章以前，我得明確地告訴您，我並非一個數據庫設計領域的大師。如下列出的 11 點是我對本身在平時項目實踐和閱讀中學習到的經驗總結出來的我的看法。我我的認爲它們對個人數據庫設計提供了很大的幫助。實屬一家之言，歡迎拍磚 : )

我之因此寫下這篇這麼完整的文章是由於，不少開發者一參與到數據庫設計，就會很天然地把 「三範式」 看成銀彈同樣來使用。他們每每認爲遵循這個規範就是數據庫設計的惟一標準。因爲這種心態，他們每每儘管一路碰壁也會堅持把項目作下去。

你們都說標準規範是重要的指導方針而且也這麼作着，可是把它看成石頭上的一塊標記來記着（死記硬背）仍是會帶來麻煩的。如下 11 點是我在數據庫設計時最優先考慮的規則。

規則 1：弄清楚將要開發的應用程序是什麼性質的（OLTP 仍是 OPAP）？

當你要開始設計一個數據庫的時候，你應該首先要分析出你爲之設計的應用程序是什麼類型的，它是 「事務處理型」（Transactional） 的仍是 「分析型」 （Analytical）的？你會發現許多開發人員採用標準化作法去設計數據庫，而不考慮目標程序是什麼類型的，這樣作出來的程序很快就會陷入性能、客戶定製化的問題當中。正如前面所說的，這裏有兩種應用程序類型， 「基於事務處理」 和 「基於分析」，下面讓咱們來了解一下這兩種類型究竟說的是什麼意思。

事務處理型：這種類型的應用程序，你的最終用戶更關注數據的增查改刪（CRUD，Creating/Reading/Updating/Deleting）。這種類型更加官方的叫法是 「OLTP」 。

分析型：這種類型的應用程序，你的最終用戶更關注數據分析、報表、趨勢預測等等功能。這一類的數據庫的 「插入」 和 「更新」 操做相對來講是比較少的。它們主要的目的是更加快速地查詢、分析數據。這種類型更加官方的叫法是 「OLAP」 。

那麼換句話說，若是你認爲插入、更新、刪除數據這些操做在你的程序中更爲突出的話，那就設計一個規範化的表不然的話就去建立一個扁平的、不規範化的數據庫結構。

如下這個簡單的圖表顯示了像左邊 Names 和 Address 這樣的簡單規範化的表，怎麼經過應用不規範化結構來建立一個扁平的表結構。

 

規則 2：將你的數據按照邏輯意義分紅不一樣的塊，讓事情作起來更簡單

這個規則其實就是 「三範式」 中的第一範式。違反這條規則的一個標誌就是，你的查詢使用了不少字符串解析函數

例如 substring、charindex 等等。若真如此，那就須要應用這條規則了。

好比你看到的下面圖片上有一個有學生名字的表，若是你想要查詢學生名字中包含「Koirala」，但不包含「Harisingh」的記錄，你能夠想象一下你將會獲得什麼樣的結果。

因此更好的作法是將這個字段拆分爲更深層次的邏輯分塊，以便咱們的表數據寫起來更乾淨，以及優化查詢。

規則 3：不要過分使用 「規則 2」

開發者都是一羣很可愛的生物。若是你告訴他們這是一條解決問題的正路，他們就會一直這麼作下去，作到過了頭致使了一些沒必要要的後果。這也能夠應用於咱們剛剛在前面提到的規則2。當你考慮字段分解時，先暫停一下，而且問問你本身是否真的須要這麼作。正如所說的，分解應該是要符合邏輯的。

例如，你能夠看到電話號碼這個字段，你不多會把電話號碼的 ISD 代碼單獨分開來操做（除非你的應用程序要求這麼作）。因此一個很明智的決定就是讓它保持原樣，不然這會帶來更多的問題。

規則 4：把重複、不統一的數據當成你最大的敵人來對待

集中那些重複的數據而後重構它們。我我的更加擔憂的是這些重複數據帶來的混亂而不是它們佔用了多少磁盤空間。

例以下面這個圖表，你能夠看到 「5th Standard」 和 「Fifth standard」 是同樣的意思，它們是重複數據。如今你可能會說是因爲那些錄入者錄入了這些重複的數據或者是差勁的驗證程序沒有攔住，讓這些重複的數據進入到了你的系統。如今，若是你想導出一份將本來在用戶眼裏十分困惑的數據顯示爲不一樣實體數據的報告，該怎麼作呢？

解決方法之一是將這些數據完整地移到另一個主表，而後經過外鍵引用過來。在下面這個圖表中你能夠看到咱們是如何建立一個名爲 「Standards」（課程級別） 的主表，而後一樣地使用簡單的外鍵鏈接過去。

規則 5：小心被分隔符分割的數據，它們違反了「字段不可再分」

前面的規則 2 即「第一範式」說的是避免 「重複組」 。下面這個圖表做爲其中的一個例子解釋了 「重複組」是什麼樣子的。若是你仔細的觀察 syllabus（課程） 這個字段，會發如今這一個字段裏實在是填充了太多的數據了。像這些字段就被稱爲 「重複組」 了。若是咱們又得必須使用這些數據，那麼這些查詢將會十分複雜而且我也懷疑這些查詢會有性能問題。

這些被塞滿了分隔符的數據列須要特別注意，而且一個較好的辦法是將這些字段移到另一個表中，使用外鍵鏈接過去，一樣地以便於更好的管理。

 

那麼，讓咱們如今就應用規則2（第一範式） 「避免重複組」 吧。你能夠看到上面這個圖表，我建立了一個單獨的 syllabus（課程） 表，而後使用 「多對多」 關係將它與 subject（科目） 表關聯起來。

經過這個方法，主表（student 表）的 syllabus（課程） 字段就再也不有重複數據和分隔符了。

規則 6：小心那些僅僅部分依賴主鍵的列

 

留心注意那些僅僅部分依賴主鍵的列。例如上面這個圖表，咱們能夠看到這個表的主鍵是 Roll No.+Standard。如今請仔細觀察 syllabus 字段，能夠看到 syllabus（課程） 字段僅僅關聯（依賴） Standard（課程級別） 字段而不是直接地關聯（依賴）某個學生（Roll No. 字段）。

Syllabus（課程） 字段關聯的是學生正在學習的哪一個課程級別（Standard 字段）而不是直接關聯到學生自己。那若是明天咱們要更新教學大綱（課程）的話還要痛苦地爲每一個同窗也修改一下，這明顯是不符合邏輯的（不正常的作法）。更有意義的作法是將這些字段從這個表移到另一個表，而後將它們與 Standard（課程級別）表關聯起來。

你能夠看到咱們是如何移動 syllabus（課程）字段而且一樣地附上 Standard 表。

這條規則只不過是 「三範式」 裏的 「第二範式」：「全部字段都必須完整地依賴主鍵而不是部分依賴」。

規則 7：仔細地選擇派生列

若是你正在開發一個 OLTP 型的應用程序，那強制不去使用派生字段會是一個很好的思路，除非有迫切的性能要求，好比常常須要求和、計算的 OLAP 程序，爲了性能，這些派生字段就有必要存在了。

經過上面的這個圖表，你能夠看到 Average 字段是如何依賴 Marks 和 Subjects 字段的。這也是冗餘的一種形式。所以對於這樣的由其餘字段獲得的字段，須要思考一下它們是否真的有必要存在。

這個規則也被稱爲 「三範式」 裏的第三條：「不該該有依賴於非主鍵的列」 。 個人我的見解是不要盲目地運用這條規則，應該要看實際狀況，冗餘數據並不老是壞的。若是冗餘數據是計算出來的，看看實際狀況再來決定是否應用這第三範式。

規則 8：若是性能是關鍵，不要執拗地去避免冗餘

不要把 「避免冗餘」 看成是一條絕對的規則去遵循。若是對性能有迫切的需求，考慮一下打破常規。常規狀況下你須要作多個表的鏈接操做，而在很是規的狀況下這樣的多表鏈接是會大大地下降性能的。

規則 9：多維數據是各類不一樣數據的聚合

OLAP 項目主要是解決多維數據問題。好比你能夠看看下面這個圖表，你會想拿到每一個國家、每一個顧客、每段時期的銷售額狀況。簡單的說你正在看的銷售額數據包含了三個維度的交叉。

爲這種狀況作一個實際的設計是一個更好的辦法。簡單的說，你能夠建立一個簡單的主要銷售表，它包含了銷售額字段，經過外鍵將其餘全部不一樣維度的錶鏈接起來。

 

規則 10：將那些具備「名值表」特色的表統一塊兒來設計

不少次我都遇到過這種 「名值表」 。 「名值表」 意味着它有一些鍵，這些鍵被其餘數據關聯着。好比下面這個圖表，你能夠看到咱們有 Currency（貨幣型）和 Country（國家）這兩張表。若是你仔細觀察你會發現實際上這些表都只有鍵和值。

 

對於這種表，建立一個主要的表，經過一個 Type（類型）字段來區分不一樣的數據將會更有意義。

規則 11：無限分級結構的數據，引用本身的主鍵做爲外鍵

咱們會常常碰到一些無限父子分級結構的數據（樹形結構？）。例如考慮一個多級銷售方案的狀況，一個銷售人員之下能夠有多個銷售人員。注意到都是 「銷售人員」 。也就是說數據自己都是一種。可是層級不一樣。這時候咱們能夠引用本身的主鍵做爲外鍵來表達這種層級關係，從而達成目的。

這篇文章的用意不是叫你們不要遵循範式，而是叫你們不要盲目地遵循範式。根據你的項目性質和須要處理的數據類型來作出正確的選擇。