變量/函數/過程/ etc名稱是否影響PL/SQL中的性能？

我幾乎是一個從「Java世界」到「PL/SQL世界」，與「傳統」存儲過程一起工作的新手，我有一個問題。 Java命名的最佳實踐包括諸如「變量的名稱，方法，類等應該是有意義和自動記錄的」（我在Clean Coder書上閱讀）。默認情況下，Oracle的標識符長度爲30個字符，但我發現縮寫的命名並不總是「易於翻譯」，我不知道這是否完成了關於應用程序性能的思考，或者它只是「一種糟糕的做法」。變量/函數/過程/ etc名稱是否影響PL/SQL中的性能？

Supose我找到了這樣的事情：

PROCEDURE PROCCALCTAXES(vVarNamTax VARCHAR2(2)) IS 
    vVarNamCouCalTax VARCHAR2(20); 
    nVarCouId NUMBER; 
    vVarNamTax VARCHAR2(20); 
    vVarValTax VARCHAR2(10); 
    nVarCouTaxTimPaid NUMBER; 
    vVarExa30Cha VARCHAR2(10); 
BEGIN 
    --business logic 
END PROCDOSTH;

有些東西如果我重構像這樣的代碼來照顧？

PROCEDURE P_CALCULATE_TAXES(vVarNamTax VARCHAR2(2)) IS 
    vCountryName VARCHAR2(20); 
    nCountryId NUMBER; 
    vTaxName VARCHAR2(20); 
    vTaxValue VARCHAR2(10); 
    nCountOfTimesPaid NUMBER; 
    vAnExampleWith30CharactersLong VARCHAR2(10); 
BEGIN 
    --business logic 
END P_CALCULATE_TAXES;

應用程序的性能下降了嗎？如果所有變量都像最後一個變量那樣有30個字符呢？什麼時候函數/過程/觸發器/等的名稱會影響性能？這是否有一個標準？

謝謝！

來源

2015-03-13 Ivancho

與性能無關，與可維護性和名稱空間管理有關。最好的做法是將所有程序封裝在軟件包中，例如'TAX_PKG.calculate'或'FINANCE.calculate_tax'或其他在您的上下文中有意義的內容。 – 2015-03-14 14:16:24

你一定要讓名字更具可讀性，有意義並且自動記錄。很難遇到任何語言，在描述性名稱不利的情況下（至少在性能方面，由於長度限制，可能會在某些特定語言的語言中）。 Sql和PL/Sql沒有什麼不同。該名稱不會影響性能。

儘管有30個字符的限制，如果你在一個擁有多個開發人員的組織中，你應該考慮爲參數名稱，變量名稱，全局變量，視圖的任何種類的前綴/後綴，觸發器，程序，包裹等。

您可以訪問http://www.toadworld.com/platforms/oracle/w/wiki/8245.plsql-standards.aspx查看不同的人爲他們採用的一些標準示例。沒有硬性規定說如果某件事是對的或有什麼不對的。但是某些標準肯定有助於提高代碼的可讀性和可維護性，並可能有助於更快地編寫未來的代碼。

至於你的榜樣，我將完全鼓勵PROCCALCTAXES更名爲更具可讀性像CALCULATE_TAXES或者如果你通過P_或PRC_採用了標準的前綴程序，這是你的，但在我看來冗餘和在30個角色空間中佔據寶貴的房地產。

我發現有用的另一件事是提出適用於我們公司的標準縮寫列表。像組織的ORG，地址的ADDR，客戶的CUST等等。有助於適合30個字符的限制。

來源

2015-03-13 16:03:28 ruudvan

變量名稱對性能沒有影響。

無論語言如何，變量名都應該清晰並且自我記錄。考慮到PL/SQL變量名稱限制爲30個字符，但是，清晰和自我記錄可能涉及某種一致的縮寫。如果我知道的，例如，我將有很多不同的變量

order_id 
order_line_id 
order_line_amount 
order_total_amount 
order_sales_tax_rate 
order_sales_tax_amount 
order_sales_tax_taxing_entity_name 
order_sales_tax_taxing_entity_fips_code

其中的一些變量將超過30個字符，它通常是有意義的縮寫他們都一致，而不是隻縮寫那些會超過30個字符的變量。在這種情況下，爲了確保我的所有變量少於30個字符，我可能希望將「order」縮寫爲「ordr」，「sales_tax」爲「stax」，並將「taxing_entity」縮寫爲「txety」。迫使開發人員知道這些縮寫（並始終堅持這些縮寫）將會降低代碼的可讀性，但這種打擊可能不足以迫使開發人員弄清楚是否在一個變量中縮寫「sales_tax」，而不是另一個變量。

來源

2015-03-13 16:13:29

在我看來它沒有任何意義，以便使用像「PROC CALCTAXES」或「VVAR NamTax」的名稱，以表明他們是程序或VARCHAR變量。無論如何，幾乎每個編輯器或IDE都默認顯示這些信息。使用這些字符來提供更多可讀的名稱。

來源

2015-03-13 17:35:13

變量/函數/過程/ etc名稱是否影響PL/SQL中的性能？

回答

相關問題