Изменяет ли переменные/функции/процедуры/etc имя на производительность в PL/SQL?

Question

Я почти новичок, пришедший из «мира Java» в «мир PL/SQL», работая с «устаревшими» хранимыми процедурами, и у меня есть вопрос. Наилучшие практики для именования Java включают в себя такие советы, как «имена переменных, методы, классы и т. Д., Должны быть значимыми и автоматически документированы» (я читал в книге «Чистый кодер»). По умолчанию идентификаторы Oracle имеют длину 30 символов, но я нашел сокращенное имя, которое не всегда «легко переводится», и я не знаю, было ли это сделано, думая о производительности приложения, или это «просто плохая практика», ,

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 символами? Когда значение функции/процедуры/триггер/etc влияет на производительность? Есть ли стандарт для этого?

Спасибо!

Answer 1

Вы должны сделать имена более читабельными, значимыми и автоматическими документами. Было бы трудно найти какой-либо язык, на котором более описательное имя было бы невыгодным (возможно, на некоторых языках с особыми ограничениями из-за ограничений длины), по крайней мере, с точки зрения производительности. 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 символов.

Answer 2

Имена переменных не влияют на производительность.

Независимо от языка, имена переменных должны быть четкими и самодокументируемыми. Учитывая, что имена переменных 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 символов. В этом случае я могу последовательно сокращать «порядок» как «ordr», «sales_tax» как «stax» и «taxing_entity» как «txety», чтобы гарантировать, что все мои переменные составляют менее 30 символов. Заставляя разработчиков знать эти сокращения (и придерживаться их последовательно), будет уменьшаться читаемость вашего кода, но это, вероятно, меньше, чем заставить разработчиков разобраться, сокращен ли вы «sales_tax» в одной переменной, но не в другой.

Answer 3

На мой взгляд, это не имеет никакого смысла использовать такие имена, как «PROC CALCTAXES» или «vVar NamTax» для того, чтобы показать, что они являются процедуры или VARCHAR переменные. Почти каждый редактор или IDE показывает такую ​​информацию по умолчанию. Используйте символы, чтобы дать более читаемые имена.