Gojko Adzic составил очень любопытный документ Oracle SQL and PL/SQL Bad Practices. А я позволил себе немного его прокомментировать.
Сколько людей — столько мнений. Однозначно разделить на bad и best practice не выйдет.
Using non-deterministic functions directly in conditions. +1 Использование функций в условиях (WHERE) — зло и жестоко бьет по производительности.
Catch-all error handling. 0 — Зависит от выбранного Вами способа обработки ошибок. Будет ли логирование уже на DB уровне или все ошибки наверху обрабатывать.
Client access as object owner. +1. Для внешних приложений должно быть определенно API, на каком уровне его делать это другая задача, но пускать «козлов в огород» не стоит.
Client access to tables. +1. Меньше знаешь — лучше спишь, про write можно вообще забыть, читать позволить можно лучше через views либо через API.
Embedding complex SQL code into PL/SQL. -1. Не понял, что же здесь плохого.
Error handling with magic numbers. 0 — «it’s depend». Все зависит от способа обработок ошибок, — какой из них лучший или правильный, или более удобный решать Вам.
Error handling with output parameters. +1. Несмотря на предыдущий пункт. Процедура с REF CURSOR OUT и OUT переменой индицирующий успешный вызов или нет — откроет Вам глаза на проблему.
Formatting data in views. +1. Конвертация типа Date в строку — типичная проблема. Зачем это делать? (А ведь делают.)
Hardcoding local Varchar2 variable size +1. Только это относится ко всем типам, а не только к VARCHAR2, Случаи использования для переменных NUMBER(5) и присваивать туда значение из поля с типом NUMBER(12), а еще лучше NUMBER(24,8), довольно частые.
Ignoring exceptions. +1. Только здесь речь идет не об игнорировании — речь идет о «сокрытии» ошибок.
begin
…
Exception
When others then
NULL;
end;
Not using bound variables for changing parameters. +1. Оптимизатору надо помогать, а не запутывать его.
Relying on conditional column predicates in triggers. +2 Костылями надо пользоваться только в крайних случаях.
Relying on context information in package variables. +2 Глобальные переменные не есть хорошо. Таблиц мало?
Relying on external context initialisation. 0 == +1 + -1. Но без комментариев, Потому что решение тоже не понравилось.
Secondary processing with unshielded triggers. +2. Почему смотрите выше.
Storing ROWID for later reference. +1. Есть sequences.
Storing empty LOBs. +1. Вообще, зачем их хранить?
Too many levels of views. +1. Oracle system views видели? План выполнения видели? Для некоторых в 40 строк не умещается.
Transactional control in non-autonomous procedures. +1. Наступал.
Trigger depending on order of execution. +2. Почему? Смотрите выше.
Using Sequence nextval without curval. +1 Странно? Потому что читать надо как «Using currval without call of nextval».
Using a sequence as a counter. +1. По моему все очевидно.
Using bound variables for constants. 0. — Проблема существуют, но решение подходит только к определенному случаю. Вы знаете список значений их характер распределения значений. Вероятность не очень большая.
Using derived column values for existence checks. +1 Все прозрачно и ясно.
Using exceptions for flow control. +1. Зачем так делать? Пример надуманным выглядит.
Using magic numbers for non-existing values. +1 . NULL может использоваться как «значение по умолчанию». Само значение может быть определенно в другом месте. 0 и -1 конечно это не годится. Можно конечно поспорить, но если сегодня например статьи с CategoryId = NULL означают «Разное», при этом у вас есть и статьи с такой категорий, то пробивая сразу категорию «Разное», позже их разделить будет невозможно, если вы определите что статьи с CategoryId = NULL это «Новости». (Пример, конечно, высосан из пальца.)
Using non-dedicated packages for continuous jobs. 0 — Не понял что плохого. Успешность вызова grant execute зависит от того выполняется сейчас процедура из пакета или нет?
Wrapping everything into stored procedures. Самый спорный вопрос — хорошо это или плохо. Я приверженец этого подхода, правда у меня только аргумент — такой подход позволяет скрыть структуры данных от клиентской части и модификация ее производится только на одном уровне. Вообще использование или не использование этого подхода — тема отдельной статьи.
