次の方法で共有

プロシージャを使用する場合

  • [アーティクル]

プロシージャを使用すると、SQL ステートメントがアプリケーションからデータ ソースに移動するという事実に基づいて、プロシージャを使用する利点がいくつかあります。 アプリケーションに残っているのは、相互運用可能なプロシージャ呼び出しです。 以下のような特徴を持っています:

  • パフォーマンス プロシージャは、通常、SQL ステートメントを実行する最も高速な方法です。 準備された実行と同様に、ステートメントはコンパイルされ、2 つの異なる手順で実行されます。 準備された実行とは異なり、プロシージャは実行時にのみ実行されます。 これらは別の時刻にコンパイルされます。

  • ビジネス ルール - ビジネス ルール は、会社がビジネスを行う方法に関するルールです。 たとえば、Sales Person というタイトルのユーザーのみが新しい販売注文の追加を許可される場合があります。 これらのルールをプロシージャに配置すると、個々の企業は、アプリケーション コードを変更することなく、アプリケーションによって呼び出されたプロシージャを書き換えることで、バーティカルなアプリケーションをカスタマイズできます。 たとえば、注文入力アプリケーションは、固定数のパラメータを指定してプロシージャ InsertOrder を呼び出す場合があり、InsertOrder の実装方法は企業によって異なります。

  • 置換性 プロシージャにビジネス ルールを配置することと密接に関係しているのは、アプリケーションを再コンパイルせずにプロシージャを実際に置換できます。 会社がアプリケーションを購入してインストールした後にビジネス ルールが変更された場合、会社はそのルールを含む手順を変更できます。 アプリケーションの観点からは、何も変わらず、特定のタスクを実行するために、依然として特定のプロシージャを呼び出します。

  • DBMS 固有の SQL プロシージャは、アプリケーションが DBMS 固有の SQL を悪用し、引き続き相互運用可能な状態を維持する方法を提供します。 たとえば、SQL でフロー制御ステートメントをサポートする DBMS のプロシージャは、エラーからトラップして復旧する可能性があります。一方、フロー制御ステートメントをサポートしない DBMS のプロシージャは単にエラーを返す可能性があります。

  • プロシージャはトランザクションを存続 一部のデータ ソースでは、トランザクションがコミットまたはロールバックされると、接続上のすべての準備されたステートメントのアクセス プランが削除されます。 SQL ステートメントをデータ ソースに永続的に格納されるプロシージャに配置することで、ステートメントはトランザクションに残ります。 準備された状態、部分的に準備された状態、または準備されていない状態でプロシージャが存続するかどうかは、DBMS 固有です。

  • 個別の開発 プロシージャは、アプリケーションの残りの部分とは別に開発できます。 大企業では、これは高度に専門化されたプログラマのスキルをさらに活用する方法を提供する可能性があります。 つまり、アプリケーション プログラマはユーザー インターフェイス コードを記述でき、データベース プログラマはプロシージャを記述できます。

プロシージャは通常、バーティカル アプリケーションとカスタム アプリケーションで使用されます。 これらのアプリケーションは固定タスクを実行する傾向があり、プロシージャ呼び出しをハードコーディングすることができます。 たとえば、注文エントリ アプリケーションは、InsertOrder、DeleteOrder、UpdateOrder、および GetOrders プロシージャを呼び出す場合があります。

汎用アプリケーションからプロシージャを呼び出す理由はほぼありません。 プロシージャは通常、特定のアプリケーションのコンテキストでタスクを実行するように記述されるため、汎用アプリケーションには使用できません。 たとえば、スプレッドシートには、前述の InsertOrder プロシージャを呼び出す理由はありません。 さらに、汎用アプリケーションは、ステートメントの実行を高速化することを期待して、実行時のプロシージャ構築はお勧めしません。これは準備実行または直接実行よりも遅くなる可能性が高いだけでなく、DBMS 固有の SQL ステートメントも必要になります。

例外はアプリケーション開発環境です。多くの場合、プログラマはプロシージャを実行し、プログラマがプロシージャをテストする方法を提供する SQL ステートメントを構築する方法を提供します。 このような環境では、SQLProcedures を呼び出して使用可能なプロシージャと SQLProcedureColumns を一覧表示し、入力パラメーター、入力/出力パラメーター、プロシージャの戻り値、およびプロシージャによって作成された結果セットの列を一覧表示します。 ただし、このような手順は、各データ ソースで事前に開発する必要があります。そのためには、DBMS 固有の SQL ステートメントが必要になります。

プロシージャを使用するには、3 つの大きな短所があります。 1 つ目は、アプリケーションを実行する DBMS ごとにプロシージャを記述してコンパイルする必要があるということです。 これはカスタム アプリケーションでは問題ではありませんが、多数の DBMS で実行するように設計された垂直アプリケーションの開発とメンテナンス時間を大幅に短縮できます。

2 つ目の短所は、多くの DBMS でプロシージャがサポートされないことです。 繰り返しますが、これは、多数の DBMS で実行するように設計された垂直アプリケーションの問題である可能性が最も高くなります。 プロシージャがサポートされているかどうかを判断するために、アプリケーションは SQL_PROCEDURES オプションを使用して SQLGetInfo を呼び出します。

3 番目の短所は、特にアプリケーション開発環境に当てはまりますが、ODBC ではプロシージャを作成するための標準文法が定義されていないことです。 つまり、アプリケーションはプロシージャを相互運用可能に呼び出すことができますが、相互運用可能にプロシージャを作成することはできません。