三大范式:

　　第1規(guī)范：沒有重復(fù)的組或多值的列，這是數(shù)據(jù)庫設(shè)計(jì)的最低要求。

　　第2規(guī)范: 每個(gè)非關(guān)鍵字段必須依賴于主關(guān)鍵字，不能依賴于一個(gè)組合式主關(guān)鍵字的某些組成部分。消除部分依賴，大部分情況下，數(shù)據(jù)庫設(shè)計(jì)都應(yīng)該達(dá)到第二范式。

　　第3規(guī)范: 一個(gè)非關(guān)鍵字段不能依賴于另一個(gè)非關(guān)鍵字段。消除傳遞依賴，達(dá)到第三范式應(yīng)該是系統(tǒng)中大部分表的要求，除非一些特殊作用的表。

　　更高的范式要求這里就不再作介紹了，個(gè)人認(rèn)為，如果全部達(dá)到第二范式，大部分達(dá)到第三范式，系統(tǒng)會(huì)產(chǎn)生較少的列和較多的表，因而減少了數(shù)據(jù)冗余，也利于性能的提高。

　　完全按照三大范式規(guī)范化設(shè)計(jì)的系統(tǒng)幾乎是不可能的，除非系統(tǒng)特別的小，在規(guī)范化設(shè)計(jì)后，有計(jì)劃地加入冗余是必要的。冗余可以是冗余數(shù)據(jù)庫、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。冗余可以是為了編程方便而增加，也可以是為了性能的提高而增加。從性能角度來說，冗余數(shù)據(jù)庫可以分散數(shù)據(jù)庫壓力，冗余表可以分散數(shù)據(jù)量大的表的并發(fā)壓力，也可以加快特殊查詢的速度，冗余字段可以有效減少數(shù)據(jù)庫表的連接，提高效率。

　　主鍵的設(shè)計(jì) 

　　主鍵是必要的，SQL SERVER的主鍵同時(shí)是一個(gè)唯一索引，而且在實(shí)際應(yīng)用中，我們往往選擇最小的鍵組合作為主鍵，所以主鍵往往適合作為表的聚集索引。聚集索引對(duì)查詢的影響是比較大的，這個(gè)在下面索引的敘述。

　　在有多個(gè)鍵的表，主鍵的選擇也比較重要，一般選擇總的長度小的鍵，小的鍵的比較速度快，同時(shí)小的鍵可以使主鍵的B樹結(jié)構(gòu)的層次更少。

　　主鍵的選擇還要注意組合主鍵的字段次序，對(duì)于組合主鍵來說，不同的字段次序的主鍵的性能差別可能會(huì)很大，一般應(yīng)該選擇重復(fù)率低、單獨(dú)或者組合查詢可能性大的字段放在前面。

　　外鍵的設(shè)計(jì)

　　外鍵作為數(shù)據(jù)庫對(duì)象，很多人認(rèn)為麻煩而不用，實(shí)際上，外鍵在大部分情況下是很有用的，理由是：

　　外鍵是最高效的一致性維護(hù)方法，數(shù)據(jù)庫的一致性要求，依次可以用外鍵、CHECK約束、規(guī)則約束、觸發(fā)器、客戶端程序，一般認(rèn)為，離數(shù)據(jù)越近的方法效率越高。

　　謹(jǐn)慎使用級(jí)聯(lián)刪除和級(jí)聯(lián)更新，級(jí)聯(lián)刪除和級(jí)聯(lián)更新作為SQL SERVER 2000當(dāng)年的新功能，在2005作了保留，應(yīng)該有其可用之處。我這里說的謹(jǐn)慎，是因?yàn)榧?jí)聯(lián)刪除和級(jí)聯(lián)更新有些突破了傳統(tǒng)的關(guān)于外鍵的定義，功能有點(diǎn)太過強(qiáng)大，使用前必須確定自己已經(jīng)把握好其功能范圍，否則，級(jí)聯(lián)刪除和級(jí)聯(lián)更新可能讓你的數(shù)據(jù)莫名其妙的被修改或者丟失。從性能看級(jí)聯(lián)刪除和級(jí)聯(lián)更新是比其他方法更高效的方法。

　　字段數(shù)據(jù)類型設(shè)計(jì)原則:

　　A、數(shù)據(jù)類型盡量用數(shù)字型，數(shù)字型的比較比字符型的快很多，尤其是作為主鍵。

　　B、 數(shù)據(jù)類型盡量小，這里的盡量小是指在滿足可以預(yù)見的未來需求的前提下的，節(jié)省一個(gè)字節(jié)是一個(gè)字節(jié)，雖然硬盤便宜也不能浪費(fèi)啊。

　　C、 盡量不要允許NULL，除非必要，可以用NOT NULL+DEFAULT代替。

　　為什么最好不要為null呢，因?yàn)樵诔绦蛱幚磉^程中，你經(jīng)常要為null值進(jìn)行處理，比如使用isnull進(jìn)行判斷，這樣削弱查詢的速度，還有程序中需要不斷的為null值進(jìn)行判斷，多寫了代碼，減少了程序的性能。

　　D、少用TEXT和IMAGE，二進(jìn)制字段的讀寫是比較慢的，而且，讀取的方法也不多，大部分情況下最好不用。在SQL Server 2005盡可能使用nvarchar(max), 或者varchar(max); 除非必要圖片盡量上傳到服務(wù)器，數(shù)據(jù)庫保留上傳地址。

　　E、自增字段要慎用

　　1. 不利于數(shù)據(jù)遷移；

　　2. 不利于分布式部署；

　　3. 無法預(yù)知Id，為子表數(shù)據(jù)插入造成困難；

　　4. 沒有實(shí)際意義，無法讓人看出這個(gè)數(shù)字到底有什么用。

　　F、盡可能使用定長數(shù)據(jù)類型，而不是變長數(shù)據(jù)類型。

　　為什么不要設(shè)計(jì)過多的變長類型的數(shù)據(jù)呢?

　　1. 對(duì)于 SQl Server 為說，變長類型的數(shù)據(jù)，在更新的時(shí)候，如果長度比以前的大，會(huì)進(jìn)行頁拆分。會(huì)對(duì)查詢性能造成嚴(yán)重的影響。會(huì)增加查詢時(shí)，I/O 的花費(fèi) (Cost) 頁分隔越多，查詢時(shí)，I/O 的開銷就越大。對(duì)于變長的字段來說，有可能這個(gè)字符的內(nèi)容存儲(chǔ)在不同的位置，這個(gè)字段的內(nèi)容存儲(chǔ)在不同的位置。存儲(chǔ)在不同的頁中, 它們之間有指針來關(guān)聯(lián)。這種情況會(huì)造成查詢時(shí)，磁頭來回尋址，定位。可能你查一條記錄，磁頭找這條記錄的這個(gè)變長字段的內(nèi)容，都要去好幾個(gè)頁里找，才能完整的找到。這樣，就造成了很大個(gè) I/O 開銷，降低了查詢性能。從物理上來說，文件本來就經(jīng)常容易產(chǎn)生碎片。再加上變長類型的頁拆分。

　　頁是SQL Server存儲(chǔ)數(shù)據(jù)的基本單位，大小為8kb，可以存儲(chǔ)表數(shù)據(jù)、索引數(shù)據(jù)、執(zhí)行計(jì)劃數(shù)據(jù)、分配位圖、可用空間信息。頁是SQL  Server可以讀寫的最小I/O單位。即便是讀取一行數(shù)據(jù)，它也要把整個(gè)頁加載到緩存并從緩存中讀取數(shù)據(jù)。

　　頁拆分是這樣產(chǎn)生的:

　　比如：有一個(gè)變長類型的字段 Content: nvarchar(512)。你添加一條記錄，給 Content 的值是 N'ABC'，那么，存儲(chǔ)的時(shí)候，直接就存儲(chǔ) N'ABC' 了。當(dāng)你下次 Update 這條記錄的 Content 字段時(shí)，給的值是 N'ABCDEF'，那么就會(huì)發(fā)生頁拆分。DEF 對(duì)被存儲(chǔ)在其它頁。因?yàn)橛锌赡苌弦淮畏峙涞臄?shù)據(jù)頁已經(jīng)存儲(chǔ)了其他行的數(shù)據(jù)對(duì)吧，對(duì)，512，只是用來限制這個(gè)字段的長度。并不與頁拆分有關(guān)系。記錄的物理順序，與你 INSERT 的順序是一致。你 INSERT 了 N條，然后再去修改第一條，這時(shí)候可能不在同一個(gè)頁了。

　　以上結(jié)論就是把變長字段的內(nèi)容加大，就會(huì)造成頁拆分了。也就是說可變長類型是把一頁填滿，再填另一頁，影響比較大的是，每次insert的時(shí)候會(huì)增加分配數(shù)據(jù)頁的次數(shù)。

　　當(dāng)然有可能造成一行數(shù)據(jù)保存在2個(gè)數(shù)據(jù)頁里。但是，同樣，不但頁拆分對(duì)增加查詢時(shí)的 I/O 開銷，字符不必要的太長，也會(huì)增加 I/O 開銷。

　　2. 字段大小對(duì)表總大小有影響

　　SQL Server 2005單行字段總長是8060字節(jié)。

　　3. 可變長類型是有長度限制的

　　以上內(nèi)容是第一篇，請(qǐng)大家多多發(fā)表意見!

it知識(shí)庫：小溫談數(shù)據(jù)庫優(yōu)化--數(shù)據(jù)設(shè)計(jì)篇，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。