為了不與其他項目或者其他系統、子系統的表重名；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

觸發器的功能通常可以用其他方式實現。在調試程序時觸發器可能成為干擾。假如你確實需要采用觸發器，一定要經過測試再應用在生產系統中，而且必須集中對它文檔化。

請把程序包、存儲過程、函數、觸發器，與應用程序一同加入CVS中，進行版本控制。因為此四者包含了代碼，應用程序對他們的依賴程度比對表、視圖的依賴程度更高；

適量但盡量少使用存儲過程、函數、觸發器。使用存儲過程、函數、觸發器的影響：

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

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

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

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

過長的函數實現，應將其語句按實現的功能分段加以概括性說明；

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

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

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

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

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

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

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

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

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

系統可能選擇基于規則的優化器，所以將結果集返回數據量小的表作為驅動表，即將結果集返回數據量小的表放在FROM后邊最后一個表；

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

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

盡量避免對索引列進行計算。如對索引列計算較多，請提請數據庫管理員建立函數索引；

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

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

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

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

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

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

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

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

= 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；

盡量避免在循環中使用SQL語句；

在循環中盡量使用動態SQL語句提高執行性能；