在日常的數據庫開發過程中，很多開發者一參與到數據庫設計，就會很自然地把 “三范式” 當作自己的信條。他們往往認為遵循這個規范就是數據庫設計的唯一標準。由于這種心態，他們往往盡管一路碰壁也會堅持把項目做下去。

對于這種現象，中培偉業《 Oracle數據庫管理與性能調優實踐》培訓專家袁老師指出，一些規范當然很重要，但是不需要死記硬背，只要掌握一些規則即可。袁老師在這里分享了11個在數據庫設計過程中應該遵守的規則。

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

當你要開始設計一個數據庫的時候，你應該首先要分析出你為之設計的應用程序是什么類型的，它是 “事務處理型”（Transactional） 的還是 “分析型” （Analytical）的？你會發現許多開發人員采用標準化做法去設計數據庫，而不考慮目標程序是什么類型的，這樣做出來的程序很快就會陷入性能、客戶定制化的問題當中。正如前面所說的，這里有兩種應用程序類型， “基于事務處理” 和 “基于分析”

規則 2：將你的數據按照邏輯意義分成不同的塊，讓事情做起來更簡單

這個規則其實就是 “三范式” 中的第一范式。違反這條規則的一個標志就是，你的查詢使用了很多字符串解析函數

規則 3：不要過度使用 “規則 2”

開發者都是一群很可愛的生物。如果你告訴他們這是一條解決問題的正路，他們就會一直這么做下去，做到過了頭導致了一些不必要的后果。這也可以應用于我們剛剛在前面提到的規則2。當你考慮字段分解時，先暫停一下，并且問問你自己是否真的需要這么做。正如所說的，分解應該是要符合邏輯的。

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

集中那些重復的數據然后重構它們。我個人更加擔心的是這些重復數據帶來的混亂而不是它們占用了多少磁盤空間。

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

前面的規則 2 即“第一范式”說的是避免 “重復組” 。這些被塞滿了分隔符的數據列需要特別注意，并且一個較好的辦法是將這些字段移到另外一個表中，使用外鍵連接過去，同樣地以便于更好的管理。

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

留心注意那些僅僅部分依賴主鍵的列。你可以看到我們是如何移動 syllabus（課程）字段并且同樣地附上 Standard 表。這條規則只不過是 “三范式” 里的 “第二范式”：“所有字段都必須完整地依賴主鍵而不是部分依賴”。

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

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

規則 8：如果性能是關鍵，不要固執地去避免冗余

不要把 “避免冗余” 當作是一條絕對的規則去遵循。如果對性能有迫切的需求，考慮一下打破常規。常規情況下你需要做多個表的連接操作，而在非常規的情況下這樣的多表連接是會大大地降低性能的。

規則 9：多維數據是各種不同數據的聚合

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

為這種情況做一個實際的設計是一個更好的辦法。簡單的說，你可以創建一個簡單的主要銷售表，它包含了銷售額字段，通過外鍵將其他所有不同維度的表連接起來。

規則 10：將那些具有“名值表”特點的表統一起來設計

這種 “名值表”往往比較常見  “名值表” 意味著它有一些鍵，這些鍵被其他數據關聯著。

規則 11：無限分級結構的數據，引用自己的主鍵作為外鍵

我們會經常碰到一些無限父子分級結構的數據（樹形結構？）。例如考慮一個多級銷售方案的情況，一個銷售人員之下可以有多個銷售人員。注意到都是 “銷售人員” 。也就是說數據本身都是一種。但是層級不同。這時候我們可以引用自己的主鍵作為外鍵來表達這種層級關系，從而達成目的。