Когда следует использовать процедуры

Существует ряд преимуществ использования процедур, основанных на том, что использование процедур перемещает инструкции SQL из приложения в источник данных. Что осталось в приложении, является вызовом процедуры взаимодействия. Это следующие преимущества.

• Процедуры производительности обычно являются самым быстрым способом выполнения инструкций SQL. Как и подготовленное выполнение, инструкция компилируется и выполняется в двух отдельных шагах. В отличие от подготовленного выполнения, процедуры выполняются только во время выполнения. Они компилируются в другое время.

• Бизнес-правила — это правило о том, как компания делает бизнес. Например, может быть разрешено добавлять новые заказы на продажу только у кого-то с заголовком "Продавец". Размещение этих правил в процедурах позволяет отдельным компаниям настраивать вертикальные приложения путем перезаписи процедур, вызываемых приложением, без необходимости изменять код приложения. Например, приложение записи заказа может вызывать процедуру InsertOrder с фиксированным числом параметров. Точно так же, как реализуется InsertOrder, может отличаться от компании до компании.

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

• Процедуры SQL , относящиеся к СУБД, позволяют приложениям использовать SQL для конкретных СУБД и по-прежнему оставаться совместимыми. Например, процедура в СУБД, поддерживающей инструкции управления потоками в SQL, может перехватывать и восстанавливаться после ошибок, в то время как процедура в СУБД, которая не поддерживает инструкции управления потоками, может просто вернуть ошибку.

• Процедуры сохраняют транзакции в некоторых источниках данных, планы доступа для всех подготовленных инструкций подключения удаляются при фиксации или откате транзакции. Поместив инструкции SQL в процедуры, которые постоянно хранятся в источнике данных, инструкции сохраняются в транзакции. Существуют ли процедуры в подготовленном, частично подготовленном или неподготовленном состоянии, зависят от СУБД.

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

Процедуры обычно используются вертикальными и пользовательскими приложениями. Эти приложения, как правило, выполняют фиксированные задачи, и в них можно выполнять вызовы процедур жесткого кода. Например, приложение записи заказа может вызывать процедуры InsertOrder, DeleteOrder, UpdateOrder и GetOrders.

Мало оснований вызывать процедуры из универсальных приложений. Процедуры обычно записываются для выполнения задачи в контексте конкретного приложения и поэтому не используются для универсальных приложений. Например, электронная таблица не имеет оснований вызывать процедуру InsertOrder только упоминание. Кроме того, универсальные приложения не должны создавать процедуры во время выполнения в надежде ускорить выполнение инструкций; Это не только может быть медленнее, чем подготовленное или прямое выполнение, оно также требует инструкций SQL для конкретных СУБД.

Исключением из этого является среда разработки приложений, которая часто предоставляет программистам способ создания инструкций SQL, которые выполняют процедуры и могут предоставить программистам способ тестирования процедур. Такие среды вызывают SQLProcedures для перечисления доступных процедур и SQLProcedureColumns для перечисления входных, входных и выходных параметров, возвращаемого значения процедуры и столбцов всех результирующих наборов, созданных процедурой. Однако такие процедуры необходимо разработать заранее на каждом источнике данных; для этого требуются инструкции SQL, относящиеся к СУБД.

Существует три основных недостатка использования процедур. Первым является то, что процедуры должны быть написаны и скомпилированы для каждой СУБД, с которой должно выполняться приложение. Хотя это не проблема для пользовательских приложений, это может значительно увеличить время разработки и обслуживания для вертикальных приложений, предназначенных для запуска с рядом СУБД.

Второй недостаток заключается в том, что многие СУБД не поддерживают процедуры. Опять же, это, скорее всего, проблема для вертикальных приложений, предназначенных для запуска с несколькими СУБД. Чтобы определить, поддерживаются ли процедуры, приложение вызывает SQLGetInfo с параметром SQL_PROCEDURES.

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