PL/SQLは私の母国語ではありません。Oracleは、Javaでのストアドプロシージャの記述をサポートしています。PL/SQLでストアドプロシージャを作成するよりもこれを行うことの利点は何ですか。
8 に答える
オラクルの世界では、開発の一般的な順序は次のとおりです。
可能な限り、純粋に SQL で実行してください。SQL 以外のものが必要な場合は、PL/SQL を使用してください。PL/SQL ではできないことが必要な場合は、Java を使用してください。他のすべてが失敗した場合は、C を使用してください。C でそれができない場合は、ゆっくりと問題から離れてください....
PL/SQL ストアド プロシージャは、ビジネス ロジックを任意の統合テクノロジからアクセスできるレイヤーに移動するための優れた方法です。パッケージ内のビジネス ロジック (スタンドアロンの関数とプロシージャを記述しないでください。時間の経過と共に管理不能な方法で成長します) は、Java、C#、PL/SQL、ODBC などで実行できます。
PL/SQL は、純粋な SQL 以外で大量のデータを処理する最速の方法です。「一括バインディング」機能は、SQL エンジンと非常にうまく連携することを意味します。
Java ストアド プロシージャは、ネットワークまたはオペレーティング システムと対話する機能を作成するのに最適です。例としては、電子メールの送信、データの FTP 送信、テキスト ファイルへの出力と圧縮、一般的なホスト コマンド ラインの実行などがあります。
Oracle を使用する際に C をコーディングする必要はありませんでしたが、レガシー アプリケーションとの統合に使用できる可能性があります。
PL/SQLでそれを実行できない場合のみ(またはPL/SQLが遅すぎることが判明した場合、これはかなりまれだと思います)。
ケーススタディとして...私たちは本番環境(Oracle 9i)で実行されている単一のJavaストアドプロシージャを持っていました.Javaはクールだと思っていたので、元々はJavaで書かれていました。ともかく。ある日、DB がクラッシュし、再起動後に Java SP が機能しなくなりました。オラクルのサポートと何度もやり取りした後、彼らは問題が何であるかを本当に知りません。オプションではなかったもの。30分後、PL/SQLでJava SPを書き直しました。
実行速度が速くなり、oracle "native" になり、他のオブジェクトと同じデプロイ プロセスを共有し、デバッグが容易になりました。
PL/SQL は非常に有能な言語です。ストアド プロシージャを作成している場合は、Java で作業するだけでなく、時間をかけて学習してください。それはあなたが知っていることだからです。
主な利点は、PL/SQLにはないAPIと言語機能にアクセスできることです。たとえば、正規表現の処理、ファイル/ディレクトリの操作、XMLの解析に使用しました。
いくつかの欠点があります:
- 不十分なツールサポート
- JVMに対する制御の欠如
- DBAは多くの場合Javaでトレーニングされていません。本番コードをサポートするには、DBAにさらにトレーニングを提供するか、Javaのトレーニングを受けたサポートスタッフを雇う必要があります。
Javaをアプリケーションサーバーに移動することは、多くの場合、不利な点を打ち消すため、より良いアプローチです。優れたツールサポート、JVMの優れた制御があり、人気のあるアプリケーションサーバーでトレーニングを受けた人がたくさんいるので、サポートスタッフを簡単に見つけることができます。パフォーマンスヒットがデータベースから離れる機会費用がありますが、Javaをデータベースに近づけても、パフォーマンスが大幅に向上するわけではありません。
a)PL / SQLストアドプロシージャまたはb)データベース外のJavaよりもデータベースでJavaを使用する理由が間違いなく必要です。
Java を使用すると、データベースに依存しないコードを作成できます。既存のコードを再利用して、生産性を大幅に向上させることができます。
Java ストアド プロシージャが役立つと思うことの 1 つは、ファイル IO です。Java には、Oracle の UTL_FILE パッケージと比較して、はるかに豊富なファイル IO 機能のセットがあり、開発者はファイルの削除、ディレクトリの追加などを行うことができます。
PL / SQLで絶対に実行できない場合、またはJavaでパフォーマンスを向上させる場合は、Javaを使用してください。
たとえば、PL / SQLプログラム内でソケットを使用する場合(ロギング、外部呼び出しなど)、次のことができます。
- UTL_TCPを使用するPL/SQLクライアントを作成します。ただし、ネイティブPL/SQLのみを使用してUDPを実行する方法はありません。
- TCPまたはUDPソケットを使用するJavaクライアントを作成します。
最初のケースでは、リモート・サービスに問題がある場合にPL/SQLコールをバックアップできる同期ソケットがあります。さらに、(OWAのように)dbms_session.reset_packageを使用している場合は、要求ごとにソケットを再接続する必要があり、これは非常にコストがかかります。
2番目のケースでは、TCPは引き続き同期ですが、非同期の非ブロッキング動作が必要な場合は、UDPを使用できます。さらに、reset_packageはJava TCPまたはUDPソケットをリセットしないため、ティアダウン/再接続の問題に対処する必要はありません。
私は2つの問題にOracle埋め込みJavaを使用しました。
1)クエリの結果をテキストファイルにまとめてFTP経由で送信するPLSQLプロシージャを実行します。このファイルは非常に大きく、Javaを使用してZipします。
2)DBと直接接続するクライアントサーバーアプリケーションで、ユーザーが送信したパスワードをMD5でハッシュされたアプリケーション(DBユーザーパスワードではない)と比較し、パスワードがネット上をプレーンテキストで移動しないようにします。これがこの問題のより良い解決策であったかどうかはわかりません。今から質問します。:)
利点:
- クライアントとデータベースで同一のアプリケーション ロジックを共有できる
- Java API へのアクセス。各データベースがサポートする Java のバージョンに注意してください。10g は 1.4 しかサポートしていないと思います (つまり、私の仕事では、メインのコードベースが最近 1.5 に移行したため、細心の注意を払う必要があります)。
短所:
- 多数のデータベース アクセスを実行する Java ストアド プロシージャは、非常に遅くなる可能性があります。
- コードのデプロイが難しくなる
答えは決してありません。データをロードまたは処理するプログラムを作成する必要がある場合は、ネットワーク上の別のコンピューターからデータ層の外側で実行する必要があります。
外部アプリケーションをデータ層で直接実行するか、データ層でインプロセスを禁止するか、ネイティブのクエリ言語が当面の仕事により適している場合に外部言語を誤って適用することは問題なく、社内の小規模なカスタムには完全に受け入れられます。応用。彼らは単にそのアリーナの外に居場所がありません.