為了不與其他項目或者其他系統(tǒng)、子系統(tǒng)的表重名；

表示某種從屬關系，比如表明是屬于某個子系統(tǒng)、某個模塊或者某個項目等等。表示這種從屬關系的一個主要目的是，從表名能夠大概知道如何去找相關的人員。比如以子系統(tǒng)為前綴的，當看到這個表的時候，就知道有問題可以去找該子系統(tǒng)的開發(fā)和使用人員；

每個表，都必須要有主鍵。主鍵是每行數(shù)據(jù)的唯一標識，保證主鍵不可隨意更新修改，在不知道是否需要主鍵的時候，請加上主鍵，它會為你的程序以及將來查找數(shù)據(jù)中的錯誤等等，提供一定的幫助；

一個表的某列與另一表有關聯(lián)關系的時候，如果加得上的話，請加上外鍵約束。外鍵是很重要的，所以要特別強調(diào)：

適量建外鍵。為了保證外鍵的一致性，數(shù)據(jù)庫會增加一些開銷，如果有確鑿的并且是對性能影響到無法滿足用戶需求的證據(jù)，可以考慮不建外鍵。否則，還是應該建外鍵；

不要以數(shù)據(jù)操作不方便為理由而不建外鍵。是的，加上外鍵以后，一些數(shù)據(jù)操作變得有些麻煩，但是這正是對數(shù)據(jù)一致性的保護。正是因為這種保護很有效，所以最好不要拒絕它；

以缺省的方式建立外鍵(即用delete restrict方式)，以達到保護數(shù)據(jù)一致性的目的；外鍵在保護數(shù)據(jù)一致方面非常有效。如果不建外鍵，數(shù)據(jù)庫中容易出現(xiàn)垃圾數(shù)據(jù)，并且無人知曉。當數(shù)據(jù)量很大的時候，查找這些垃圾數(shù)據(jù)也是相當困難的。而應用程序在設計時，往往沒有考慮或者也無法照顧到垃圾數(shù)據(jù)。因此垃圾數(shù)據(jù)很可能造成應用程序工作不正常，并且表現(xiàn)出來的現(xiàn)象會很奇怪，讓人摸不著頭腦。

字段的寬度要在一定時間內(nèi)足夠用，但也不要過寬，占用過多的存儲空間,對于長度不確定的列，采用可變長度的數(shù)據(jù)類型如 varchar類型；

字段的類型及寬度在設計以及后面進行開發(fā)時，往往要與應用的設計、開發(fā)人員商討，以得到雙方認可的類型及寬度；

除非必要，否則盡量不加冗余列。所謂冗余列，是指能通過其他列計算出來的列，或者是與某列表達同一含義的列，或者是從其他表復制過來的列等等。冗余列需要應用程序來維護一致性，相關列的值改變的時候，冗余列也需要隨之修改，而這一規(guī)則未必所有人都知道，就有可能因此發(fā)生不一致的情況。如果是應用的特殊需要，或者是為了優(yōu)化某些邏輯很復雜的查詢等操作，可以加冗余列；

除非必要，否則盡量不使用LONG, TEXT, BLOB, CLOB, NCLOB, LONG, LONG RAW這一類的數(shù)據(jù)類型，而是使用其他可以替代的數(shù)據(jù)類型；優(yōu)先使用varchar2類型替代CHAR類型，除非列寬有嚴格的要求而且得到應用嚴格支持；

單表的記錄數(shù)一般控制在兩千萬條 (參考值，各應用可以根據(jù)實際情況進行適量調(diào)整) 以內(nèi)；

記錄數(shù)在兩千萬和兩億條之間的表一定要采用分區(qū)技術，并根據(jù)應用的使用情況創(chuàng)建合適的分區(qū)標準，單個分區(qū)內(nèi)的記錄數(shù)一般控制在兩千萬條(參考值，各應用可以根據(jù)實際情況進行適量調(diào)整)以內(nèi)，同時表的索引使用對應的分區(qū)索引；

記錄數(shù)超過兩億條的表一定要考慮信息生命周期，必須考慮歷史數(shù)據(jù)的剝離，并在應用設計中完成對歷史數(shù)據(jù)的相應處理功能(歷史數(shù)據(jù)的剝離規(guī)則須經(jīng)業(yè)務使用部門的確認)；

適當利用索引提高查詢速度：當數(shù)據(jù)量比較大，了解應用程序的會有哪些查詢，依據(jù)這些查詢需求建相應的索引；最好親自試驗一下，模擬一下生產(chǎn)環(huán)境的數(shù)據(jù)量，在此數(shù)據(jù)量下，比較一下建索引前后的查詢速度；索引對性能會有一定影響，對于DML頻繁列的索引要定期維護(重建)。但是，索引的結(jié)構(gòu)對于索引的更新(比如在插入數(shù)據(jù)的時候)是有一定優(yōu)化的，所以不要在沒有試驗以前過分夸大它對性能的影響。最終還是以試驗為準；

不要建實際用不上的索引，與上條相關，如果建的索引并不提高任何一應用中的查詢速度，則要把它刪除；有些數(shù)據(jù)庫有相關工具可以發(fā)現(xiàn)實際未被使用的索引，可以利用一下；

索引類型的選擇：要根據(jù)數(shù)據(jù)分布及應用來決定如何建立索引，一般的高基數(shù)數(shù)據(jù)列(高基數(shù)數(shù)據(jù)列是指該列有很多不同的值)時 ,建立BTree索引(一般數(shù)據(jù)庫索引的缺省類型)；當?shù)突鶖?shù)數(shù)據(jù)列(該列有大量相同的值)時，可以考慮建立位圖索引(如果所選數(shù)據(jù)庫支持的話)，但位圖索引是壓縮類型索引，所以DML(增、刪、改)的代價更高，要綜合考慮；

索引列的選擇：如果檢索條件有可能包含多列，創(chuàng)建聯(lián)合主鍵或者聯(lián)合索引，把最常用于檢索條件的列放在最前端，其他的列排在后面；不要索引使用頻繁的小型表，假如這些小表有頻繁的DML就更不要建立索引，維護索引的代價遠遠高于掃描表的代價；

主鍵索引在建立的時候一定要明確的指定名稱，不能讓系統(tǒng)默認建立主鍵索引(可能有些數(shù)據(jù)庫無法指定主鍵名，則例外)；

外鍵必須需建索引。當有一定數(shù)據(jù)量，并且經(jīng)常以外鍵所在列為關聯(lián)，進行關聯(lián)查詢時，需要建索引(可能有些數(shù)據(jù)庫自動為外鍵建索引，則例外)；

當有聯(lián)合主鍵或者聯(lián)合索引時，注意不要建重復的索引。舉例說明：

在不太清楚視圖用法的情況下，盡量不建。因為一旦建了，就有被濫用的危險；

如果需要建視圖，只要是打算長期使用的，請寫入數(shù)據(jù)庫設計中。明確它的用途、目的；

建立視圖時要明確寫出所有要選擇出的列名而不要以SELECT *來代替，可以使結(jié)構(gòu)清晰可讀性增強，也不會增加它對表的所有字段的依賴，而表是很可能修改的，特別是增加字段。就很有可能導致使用該視圖的應用程序出錯；

觸發(fā)器的功能通?？梢杂闷渌绞綄崿F(xiàn)。在調(diào)試程序時觸發(fā)器可能成為干擾。假如你確實需要采用觸發(fā)器，一定要經(jīng)過測試再應用在生產(chǎn)系統(tǒng)中，而且必須集中對它文檔化。

請把程序包、存儲過程、函數(shù)、觸發(fā)器，與應用程序一同加入CVS中，進行版本控制。因為此四者包含了代碼，應用程序?qū)λ麄兊囊蕾嚦潭缺葘Ρ怼⒁晥D的依賴程度更高；

適量但盡量少使用存儲過程、函數(shù)、觸發(fā)器。使用存儲過程、函數(shù)、觸發(fā)器的影響：

(1) 可以減少數(shù)據(jù)庫與客戶端的交互，提高性能；(2) 有的數(shù)據(jù)庫還對他們進行了某種程度的編譯，在執(zhí)行的時候，不用再對其中的SQL等語句進行解析，從而提高速度；(3) 如果有多個應用，使用了不同的開發(fā)語言，當有某些關鍵的或者復雜邏輯希望共享，則可以考慮使用存儲過程或者函數(shù)。因為存儲過程等在數(shù)據(jù)庫一級是共享的；(4) 增強了應用對數(shù)據(jù)庫的依賴，如果打算將來移植數(shù)據(jù)庫的話，使用得越多，則移植的困難越大；數(shù)據(jù)庫中的業(yè)務邏輯越多(存儲過程等)，應用以及存儲過程等的維護難度也會增大；(5) 通常存儲過程等沒有面向?qū)ο蟮奶匦?#xff0c;不容易設計出易于擴展的結(jié)構(gòu)。當存儲過程比較復雜時，或者它們相互間的調(diào)用關系比較復雜時，可能難于維護；

盡量不要寫復雜的SQL：過于復雜的SQL可以用存儲過程或函數(shù)來代替，效率更高；甚至如果能保證不造成瓶頸的話，把條SQL拆成多條也是可以的。這與一般的編碼規(guī)范很相似的，首先是要易懂。易懂也就意味著容易維護，對較為復雜的sql語句加上注釋，說明算法、功能注釋風格：注釋單獨成行、放在語句前面。

應對不易理解的分支條件表達式加注釋；

對重要的計算應說明其功能；

過長的函數(shù)實現(xiàn)，應將其語句按實現(xiàn)的功能分段加以概括性說明；

每條復雜SQL語句均應有注釋說明(表名、字段名 主要是說明此句SQL執(zhí)行 的作用及所取得結(jié)果集的意義)；

常量及變量注釋時，應注釋被保存值的含義(必須)，合法取值的范圍(可選__) ；

可采用單行/多行注釋。(-- 或 /* */ 方式，不同數(shù)據(jù)庫可能語法不同)；

連接符or、in、and、以及＝、<=、>=等前后加上一個空格；

不要用SELECT *：SELECT語句中寫出必要的要選擇的全部列名，增強語句可讀性，避免不必要的選擇；SELECT * 增加了對所有字段的依賴，當表增加了字段后，有可能發(fā)生錯誤；此外還可能增加了數(shù)據(jù)的流量，查詢了一些實際不需要的字段；

避免長事務(Transaction)：長事務容易造成死鎖，應該避免，單個事務使用的數(shù)據(jù)庫和系統(tǒng)資源不宜超過總資源1-2%(參考值，各應用可以根據(jù)實際情況進行適量調(diào)整,這種情況不適用于數(shù)據(jù)倉庫)；

行最長不能超過80字符,同一語句不同字句之間逗號以后空格,其他分割符前空格 where子句書寫時，每個條件占一行，語句令起一行時，以保留字或者連接符開始，連接符右對齊；

多表連接時，使用表的別名來引用列；

SQL中對視圖的引用：在不太清楚視圖用法的情況下，盡量不用。只是因為視圖中有自己想要的字段就拿來用，是相當普遍和錯誤的用法。原因如下：

系統(tǒng)可能選擇基于規(guī)則的優(yōu)化器，所以將結(jié)果集返回數(shù)據(jù)量小的表作為驅(qū)動表，即將結(jié)果集返回數(shù)據(jù)量小的表放在FROM后邊最后一個表；

大量的排序操作影響系統(tǒng)性能，所以盡量減少order by和group by排序操作；

如必須使用排序操作，排序盡量建立在有索引的列上；

盡量避免對索引列進行計算。如對索引列計算較多，請?zhí)嵴垟?shù)據(jù)庫管理員建立函數(shù)索引；

盡量注意比較值與索引列數(shù)據(jù)類型的一致性(number與number比較、char與char比較)，避免使用數(shù)據(jù)庫的類型自動轉(zhuǎn)換功能；如：SELECT * FROM categoryWHERE id = ‘123’; -- id’s type is number

對于復合索引，SQL語句必須使用主索引列；

索引字段中，盡量避免使用NULL值；

對于索引的比較，盡量避免使用NOT=(!=)

查詢列和排序列與索引列次序保持一致 ；

盡量避免相同語句由于書寫格式的不同，而導致多次語法分析(減少數(shù)據(jù)庫的硬分析)，如可使用TOAD的格式化工具對SQL語句進行格式化處理;

查詢的WHERE過濾原則，應使過濾記錄數(shù)最多的條件放在最前面；

在WHERE中，數(shù)據(jù)庫函數(shù)、計算表達式等等，要盡可能將放在等號右邊。否則會使所比較的字段上的索引失效；如：

= TO_DATE(‘2001-9-01’,’yyyy-mm-dd’)AND gmt_modified< TO_DATE(‘2001-9-02’,’yyyy-mm-dd’);

SELECT　＊　FROM　service_promotionWHERE TO_CHAR(gmt_modified,’yyyy-mm-dd’)= ‘20001-09-01’;　而應使用：SELECT *FROM service_promotionWHERE gmt_modified

in、or子句常會使索引失效，盡可能不使用in、or；

盡量避免在循環(huán)中使用SQL語句；

在循環(huán)中盡量使用動態(tài)SQL語句提高執(zhí)行性能；