oracle開發規範

arthurtangel發表於2011-07-14
Oracle

規則1: 資料庫程式碼中，關鍵字大寫，其他內容小寫（在PL/SQL中可設定關鍵字自動轉換為大寫，以降低編碼時的大小寫切換）

規則2：程式塊應採用縮排風格書寫，保證程式碼可讀，風格一致，縮排格數統一為2格；

規則3：程式碼中需要空位時，統一採用空格鍵輸入，不允許用TAB鍵產生空位； 說明：不同的編輯器對TAB的空位格數設定不一致，會導致使用TAB鍵產生空位的程式碼格式混亂；

規則4：同一條語句佔用多行時，每一行的開始應是關鍵字，且關鍵字應和第一行左對齊,如確實不能從關鍵字分行，則分行處應對其上一行被分行的同類程式碼的最左邊；

建議1:對於INSERT… VALUES和UPDATE語句，一行寫一個欄位，每個欄位相對於INSERT語句空兩格，這段後面緊跟註釋（註釋語句左對齊），VALUES和INSERT左對齊，左括號和右括號與INSERT、VALUES左對齊。

建議2:INSERT…SELECT 語句時，應使每行的欄位順序對應，以每行最多不超過4 個欄位，以方便程式碼閱讀，括號的內容另起一行縮排2 格開始書寫，關鍵字單詞左對齊，左括號、右括號另起一行與左對齊。

規則1：不允許將多行語句書寫在同一行;

規則2：不允許將SQL語句寫成一行，再短的SQL也應該在謂詞處分行 ;

規則3：相對獨立的程式塊之間應加空行

規則4：不同型別的操作符混合使用時，應使用括號明確的表達運算的先後關係;

規則5：BEGIN和END應獨立成行

規則6：SQL語句中的逗號後面應增加一個空格，以使得程式碼清晰

建議1：減少控制語句的判斷次數，比如在ELSE（IF…ELSE）語句中，儘量將盡快能檢測到結果的判斷提前

建議2：儘量避免使用巢狀的IF語句，在這種情況應使用多個IF語句來判斷其可能性。

建議3：儲存過程、函式、觸發器、程式塊中定義的變數和輸入、輸出引數在命名上有所區分。

一般用’v_’開頭代表程式塊中定義的變數

一般用’p_’開頭代表輸入引數變數

一般用’x_’開頭代表輸入輸出或輸出引數變數

規則1：查詢資料時，儘量不使用SELECT *，而是給出明確的欄位，但該規則不包括SELECT COUNT(*)語句

規則2：INSERT語句應該出欄位列表

規則3：從表中同一筆記錄中獲取記錄的欄位值，須使用一SQL 語句得到，不允許分多條SQL 語句。

規則4：當一個PL/SQL 或SQL 語句中涉及到多個表時，始終使用別名來限定欄位名，這使其它人閱讀起來更方便，避免了含議模糊的引用，其中能夠別名中清晰地判斷出表名。

說明 ： 別名命名時，儘量避逸使用無意義的代號a、b 、c… ， 而應該有意義( 如表mtl_system_items_b 對應別名為msi，po_headers_all 別名對應為pha)。

規則5：確保變數和引數在型別和長度與表資料列型別和長度相匹配。

說明：如果與表資料列寬度不匹配，則當較寬或較大的資料傳進來時會產生執行異常。

規則6：一句SQL如果只訪問了單表，禁止使用表別名

規則7：運算子以及比較符左邊或者右邊只要不是連結的括弧，則空一格

規則8：任何SQL書寫單行不得超過80字元（含左邊的縮排）

規則9：無特殊情況，程式碼註釋儘量使用英文；

所有命名規則中，必須優先遵守通用規則，列入通用規範中的規則必須強制遵守

規則1：任何資料庫物件的命名，不得使用漢字；

規則2:任何命名長度不得超過30

說明：在部分資料庫中（例如ORACLE），表名長度是不可以超過30的，如果命名超過30，則可能給以後的遷移帶來麻煩

規則3：使用者物件命名應全部為小寫，且不允許使用控制符號強制轉換物件為小寫字元

說明：部分資料庫（如oracle中，系統表會記錄物件為大寫，如果使用了強制轉換為小寫，則每次訪問均要使用強制字元訪問）

規則4：命名應使用富有意義的英文，禁止使用拼音首字母，一般情況下不建議使用拼音命名；

規範5：命名不得使用資料庫保留字

說明：使用了資料庫保留字，會導致需要訪問該物件時，需要程式碼做特別的轉換才能訪問

規則1：同類業務的表，以相同的表示該類業務的英文開頭.

說明：同類業務的表以相同的英文開頭，在邏輯上清晰，且可避免維護過程中對該類表的誤操作

如下語句不符合規範(假定表wap_user和表user_login_log都屬於wap類業務)

CREATA TABLE wap.wap_user

CREATE TABLE wap.user_login_log

如下語句符合規範

CREATA TABLE wap.wap_user

CREATE TABLE wap.wap_user_login_log

規則2：同類表，如果按照時間不同建立的表，字尾格式一般情況下應為’_YYYY[MM[DD]]’格式

如下語句不符合規範（將年份2010簡寫為10，導致含義模糊）

CREATE TABLE wap.wap_user_login_1004

CREATE TABLE wap.wap_user_login_1005

如下語句符合規範

CREATE TABLE wap.wap_user_login_201004

CREATE TABLE wap.wap_user_login_201005

規則1：欄位命名應具有含義，能反映該欄位儲存的內容，如確實無法使用富有含義的欄位名，則應增加欄位備註。

規則2：同種用途的欄位，在同一個業務中的所有表中，應保持有同樣的欄位型別和欄位長度，並儘量保持一致的欄位命名,否則易導致業務介面衝突）

建議1：字元型別儘量定義為varchar型別而非char型別

說明：在資料庫儲存中，varchar型別採用變長儲存，而char型別為定長儲存，在大多數情況下，定長更浪費空間，但是定長字元的效能略高於變長字元

規則1：主鍵名稱應以”pk_”開頭，後接表名

規則1：外來鍵名應以”fk_”開頭,後接表名

規則1：唯一索引應以”uk_”+”表名_”+”欄位名”命名

規則2：普通索引應以”idx_”+”表名_”+“欄位名”命名

規則3：bitmap索引應以”bidx_”+”表名_”+“欄位名”命名

規則1：檢視命名應以“v_”+“表名[_表名[_表名]]”命名

規則1：同義詞命名要求和其所指向的物件同名

規則1：函式命名以”func_”開頭，後接函式的功能

規則1：儲存過程以“prc_”開頭，後接功能描述

規則1：包以“pkg_”開頭，後接功能描述

規則1：資料庫鏈以“dl_”+“$SID_$USER”命名

規則1：觸發器以“tri_”+表名+“_ins/del/upd”+”_before/after”命名

規則1：物化檢視以“mv_”+“表名[_表名]”命名

規則1：臨時表以“tmp_”開頭，後接功能描述

規則2：如果是在上線/割接中被重新命名的表，命名應是原表名+“_YYYYMMDD”

規則1：資料庫使用者名稱以字母開頭，字母和數字混合且長度不超過8個字元,同時，密碼必須包含小寫字母，大寫字母，數字，特殊字元四種組合且不少於8位

如下語句不符合規範(使用者名稱以數字開頭且超過8位，密碼只有小寫字母且不足8位)

CREATE USER 12345guoyue identified by guoyue;

如下語句符合規範

CREATE USER guoyue IDENTIFIED BY Oracle123456&8(;

規則1：資料庫設計文件中，必須包含表資料保留時間；

規則2：資料庫設計文件中，必須包含表在最大保留時間下的資料量；

規則3：資料庫設計文件中，如果表為分割槽表，必須包含分割槽條件；

規則4：資料庫設計文件中，必須包含表的讀寫頻率；

規則5：單SEGMENT （如單個普通表，分割槽表的單個分割槽，單個普通索引，分割槽索引的單個分割槽）原則上不得超過2GB大小；

規則6：和其他表有關聯的表，和其他表功能一致的欄位型別以及長度，儘量使用相同的列名；

規則7：禁止依靠設計資料庫表之間的主外來鍵關係來保證資料一致性；??

規則8：需要UPDATE的欄位，不得設計為分割槽條件欄位；

建議1：對於需要同步到資料倉儲的表，原則上必須包含同步頻率以及同步機制；

建議2：原則上每個表應設計一個主鍵；

建議3：原則上不建議使用大物件型別（CLOB,BLOB,LOGN）等型別欄位，如需設計這些欄位，需有特別說明；

建議4：如無特別需要，原則上，字元型別選擇變長欄位，數字型別選擇NUMBER；

建議5：如無特別需要，原則上不得設定表的併發度，壓縮等屬性；

建議6：對於易混淆的欄位，建議加上備註；

規則1：無特別說明，每個表的索引，不得超過5個；

規則2：單欄位上的索引不得超過2個；（即一個單欄位最多可在上面建立一個單欄位索引和一個組合索引包含這個欄位）

規則3：複合索引原則上不得超過3個欄位；

規則4：原則上，分割槽表的索引必須是分割槽索引；

建議1：頻繁出現在where字句裡的欄位建議建立索引；

建議2：用來和其他表關聯的欄位建議建立索引；

建議3：索引欄位建議有高的選擇性和過濾性（count(distinctid)/count(*)>0.6）；

建議4：對於列舉值較少的欄位，建議不要建立B-tree索引，建議建立bitmap索引；

建議5：在where子句裡作為函式引數的欄位，不能建立索引，不建議建立函式索引;

建議6：建立索引的時候，建議考慮到SELECT和INSERT,UPDATE,DELETE的平衡；

建議7：一般建議在查詢資料量10%以下使用索引；

建議8：WHERE子句的查詢條件構成索引欄位前導欄位；

建議9：選擇性更高的欄位放在組合欄位索引的前導欄位；

建議10：如果欄位選擇性接近，則把頻繁查詢的欄位放在前面；

建議11：如果欄位查詢頻率相同，則把表中的資料的排列順序所依據的欄位放在前面；

建議12：進行GROUP BY或者是ORDER BY的欄位應在組合欄位索引的前導欄位；

規則1：所有序列應設定CACHE值為不低於100

規則1：頻繁更新的表上，不得建立refreshfastoncommit型別的物化檢視

建議1：如非必要，不建議使用物化檢視，可採用程式控制的表來進行資料的同步

規則1：檢視中不允許出現ORDER BY排序

規則2：基於多表關聯的檢視，必須在欄位名前指定表別名

建議1：檢視的基礎資料儘量從表中獲取，儘量不要巢狀檢視

規則1：儲存過程，必須有異常捕獲程式碼

規則2：儲存過程中嚴禁使用GOTO語句進行跳轉

規則3：有迴圈更新的儲存過程，必須進行批量提交，且必須進行事物控制

規則4：儲存過程中如果開啟了dblink，則在儲存過程正常或者異常退出必須關閉所有開啟的dblink

規則5：儲存過程中如果使用了遊標，則在儲存過程正常或者異常退出必須關閉所有開啟的遊標

規則6：儲存過程中如果有更新，必須在異常捕獲程式碼中做回退操作

建議1：儲存過程每次被更新，應在註釋中說明更新的內容，更新的日期，以及更新的責任人，並且在更新前保留舊版本程式碼

規則1：函式中，如果進行了事物處理，必須有異常捕獲程式碼

建議2：函式儘量只是實現複雜的計算功能，不對資料庫進行更新操作

規範1：如無必要，不得設計觸發器，任何觸發器的設計，必須得到DBA批准

規則1：當在SQL語句中連線多個表時, 請使用表的別名並把別名字首於每個COLUMN上.這樣一來,就可以減少解析的時間並減少那些由COLUMN歧義引起的語法錯誤.

規則2：禁止進行欄位資料型別的隱式轉換，所有轉換必須進行明確的資料型別轉換

說明：隱式轉換會導致欄位上的索引失效，而進行顯式轉換，會提醒到開發人員該種操作會導致索引失效

規則3：禁止在多表關聯的時候，在非索引欄位上的關聯；

規則4：進行模糊查詢時，禁止條件中字串直接以“%”開頭；

建議1：儘量使用DECODE來簡化SQL訪問資料庫的次數

如下兩個語句實現的功能

SELECT COUNT(*)，SUM(salary)

FROM hr.employees

WHERE = department_id = 20

AND first_name LIKE ‘SMITH%’;

SELECT COUNT(*)，SUM(salary)

FROM hr.employees

WHERE = department_id = 30

AND first_name LIKE ‘SMITH%’;

可以使用DECODE改寫為如下語句

SELECT COUNT(DECODE(department_id,20,’*',NULL)) d20_count,

COUNT(DECODE(department_id,30,’*',NULL)) d30_count,

SUM(DECODE(department_id,20,salary,NULL)) d20_sal,

SUM(DECODE(department_id,30,salary,NULL)) d30_sal

FROM hr.employees

WHERE first_name LIKE ‘SMITH%’;

建議2：避免使用HAVING子句, HAVING 只會在檢索出所有記錄之後才對結果集進行過濾. 這個處理需要排序,總計等操作. 如果能通過WHERE子句限制記錄的數目,那就能減少這方面的開銷.

建議3：一次UPDATE多個欄位的時候，應一次查詢完成

建議4：使用EXISTS/NOT EXISTS替代IN/NOT IN

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/11990065/viewspace-702148/，如需轉載，請註明出處，否則將追究法律責任。

相關文章