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

Существует ряд преимуществ использования процедур, основанных на том, что использование процедур перемещает инструкции SQL из приложения в источник данных. То, что осталось в приложении, — это интероперабельный вызов процедуры. К этим преимуществам относятся следующие преимущества:

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

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

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

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

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

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

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

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

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

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

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

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