Попробуйте запрашивать каждый элемент данны) только один раз, т.е. по возможности используйте кэширование. Одно это требование часто исключает необходимость применения PL/SQL в качестве средства реализации.

Не бойтесь сортировать файлы и выполнять ORDER BY в запросах, чтобы можно было воспользоваться преимуществом обработки в точке смены объекта операции. Связанные с этим затраты обычно с лихвой компенсируются возможностью перемещения некоторых операций обработки в точку смены объекта операции, с тем, чтобы не выполнять их для каждого элемента управляющей таблицы или файла.

Не фильтруйте данные в управляющей логике, если соответстующие проверки не должны быть вынесены в профамму по другим причинам. Рассмотрим такой пример:

DECLARE CURSOR cl IS SELECT deptno , dname , active FROM dept

ORDER BY dname;-- благодаря этому журнал регистрации выглядит логичнее BEGIN

INSERT INTO run log (id, start at) VALUES (XX,SYSDATE); FOR this dept IN cl LOOP

IF this dept.active = Y THEN BEGIN

INSERT INTO new emp

SELECT * FROM emp WHERE deptno = this dept.deptno; INSERT INTO run steps (id, step, ended at)

VALUES (XX, this dept.dname, SYSDATE);

COMMIT; END; END IF; END LOOP;

UPDATE run log SET ended at = SYSDATE

WHERE id = XX; COMMIT; END; /

В данном случае гораздо проще и эффективнее поместить условие (подразделение активно) в предложение WHERE.

Обработка ошибок

Большинство из нас, конечно, сталкивались с радостными сообщениями вроде Unexpected condition 1ms occurred ( Возникла непредвиденная I

ситуация ) или даже 04FD63-unlcnown reference ( Неизвестная ссылка ). Мы ломали голову над тем, что они означают, и расстраивались, так как не знали, что именно сделали не так - если мы вообще делали что-нибудь не так. Тем не менее, мы счетали ошибки такого типа неизбежным злом и обычно повторяли свои попытки. Однако сегодня пользователи требуют сообщений, по которым можно идентифицировать ошибки и на которые можно реагировать. К тому же, если два профаммиста будут обрабатывать одну и ту же исключительную ситуацию, не имея схемы, указывающей, как обрабатывать эту ситуацию, то вряд ли они сделают это одинаково и наверняка предложат разные тексты сообщения об ошибке. Отсюда и необходимость в общем и согласованном подходе.

Рекомендуем присваивать всем возможным сбойным ситуациям абсолютно бессмысленные коды (мы говорим это совершенно серьезно) и хранить эти коды вместе с уровнем важности и текстовым описанием ошибки либо в базе данных, либо в файле. Очень важно, чтобы выдача новых номеров ошибок производилась просто, поскольку в противном случае программисты будут повторно использовать существующие номера.

Следующий шаг - предоставить стандартные подпрограммы для выдачи сообщений об ошибках. Такой подпрограмме передается номер ошибки и все необходимые параметры, а обработчик ошибок делает все остальное. Если уровень важности - фатальный (или выше), то управление профамме не возвращается; во всех остальных случаях управление передается обратно в профамму. Выбор места для выдачи сообщения об ошибке - дело подпрограммы обработки ошибок (больше инкапсуляции), но она, вероятно, должна зарегистрировать ее в файле (база данных может не работать) и (если сможет найти экранную форму или процесс, выполняющий отчет) выдать описательный текст пользователю.

Если приложение сталкивается с ошибкой, оно обязательно должно выполнять откат транзакции. Однако в случае, когда требуется откат транзакции, проектировщики иногда делают два ужасных просчета.

Первый просчет встречается в ситуации, когда перед выдачей команды отката транзакции вы делаете что-то еще, в частности помещаете на экран пользователя окно с таким, например, сообщением:

Fatal error encountered Press OK to abort process

или, что еще хуже:

Severe error encountered Press Abort or Retry

Если вы потратили десять минут на ввод данных и получили второе сообщение, то что вы сделаете? Вы станете нажимать кнопку Retry снова и снова в надежде, что профамма все-таки заработает и вам удастся избежать потери сделанной работы. К сожалению, если профамма перед выдачей этих

сообщений пользователю сняла ряд важных блокировок, результатом может быть полное блокирование приложения.

Второй, еще более забавный, просчет заключается в регистрации действий приложения в базе данных для содействия устранению фатальной ошибки. Очевидно, что когда программа производит откат транзакции, то она выполняет откат и для всех элементов журнала регистрации. Решения просты: выполнить фиксацию вместо отката транзакции (разве можно без шуток?) или выполнять регистрацию в файлах, а не в базе данных. В версии 7.3 реализовать файловое решение несколько проще, чем в предыдущих, так как из PL/SQL теперь можно выполнять запись в файлы на сервере. Хотя безопасность при этом оставляет желать лучшего, поскольку эти файлы могут содержать в диагностической информации важные данные, на которые может случайно натолкнуться пользователь. В более ранних версиях регистрацию в файлы можно выполнять, посылая сообщения посредством DBMS PIPE в выделенный серверный процесс, если обработка ошибок производится в основном через хранимые процедуры. Не поддавайтесь искушению использовать DBMS ALERT, поскольку соответствующие механизмы имеют транзакционный характер, т.е. подвержены фиксации и откату.

Некоторые думают, что решение с фиксацией приемлемо в тестовых системах, но мы считаем его неоправданным в любых обстоятельствах. Если вы не завершили транзакцию (например, выполнили только три из пяти операций вставки, а потом получили сообщение Duplicate value in index), то фиксация незавершенной транзакции и нарушение целостности базы данных - непрофессиональное решение.

Примечание

Вы можете создать прослушивающий процесс, написанный полностыо на PL/SQL, который будет ожидать сообщения, передаваемые с помощью пакета DBMS PIPE. Когда процесс получает такое сообщение, он регистрирует его в базе данных, выполняет фиксацию и возвращается в состояние ожидания, готовясь к следующему сообщению. Следующий уровень сложности - организация поддержки сообщения Stop, чтобы можно было дать прослушивающему процессу команду на выход. Обеспечивая регистрацию событий в базе данных, можно извлекать и сортировать эти данные с помощью любого генератора отчетов, что может принести существенную выгоду. Однако учтите, что перед тем как применять этот метод для регистрации большого числа событий в приложениях, в которых предъявляются высокие требования к времени реакции или пропускной способности, необходимо проверить последствия передачи более одного-двух канальных сообщений в секунду на конкретной платформе и версии Oracle?.