2

クエリを返すSYS_RECURSORまたは呼び出すプロシージャを呼び出すと、パフォーマンスが向上しますか？

例えば

CREATE OR REPLACE PROCEDURE my_proc
(
  p_id number,
  emp_cursor IN OUT SYS_REFCURSOR
)
AS
BEGIN

OPEN emp_cursor for
select * from emp where emp_number=p_id
end;
/

Javaパラメータを登録しOUT、パラメータを渡して上記を呼び出し、IN結果を取得します。

または

からJava結果を取得emp tableから

preparedStatement = prepareStatement(connection, "select * from emp where emp_number=?", values); 
resultSet = preparedStatement.executeQuery();

上記のどれから呼び出すのが良いオプションJavaですか？

4

2 に答える 2

1

prepareStatementメソッドがすべてのバインド変数に適切な型を使用していると仮定すると、パフォーマンスに違いはありません。つまり、パラメータのデータ型に応じて、、、などをsetLong呼び出していることを確認する必要があります。データを誤ってバインドする場合（つまり、数値をバインドするために呼び出す場合）、Oracleにデータ型変換を強制する可能性があります。これにより、オプティマイザがパフォーマンスを向上させるインデックスを使用できなくなる可能性があります。setDatesetStringsetString

ただし、コードの編成と保守の観点からは、Javaアプリケーションではなくデータベースにクエリを配置したいと思います。たとえば、クエリが不適切なプランを使用していることがわかった場合、クエリがJavaアプリケーションに埋め込まれている場合よりも、クエリがストアドプロシージャにある場合の方が、DBAが問題に対処する方がはるかに簡単です。empクエリがデータベースに保存されている場合、テーブルを変更する必要がある場合に何が影響を受けるかを判断するなどの必要がある場合は、データベースの依存関係追跡関数を使用して、影響分析をより簡単に行うこともできます。

于 2012-06-10T19:43:47.387 に答える
1

そうですね、 Java呼び出しの観点からは大きな違いはないと思います。

私が考えることができるいくつかの違いは次のとおりです。

  • ここで、Javaコードとストアドプロシージャの2つの異なるコードベースを維持する必要があります。エラーが発生した場合は、2つの異なる場所でデバッグし、2つの異なる場所で問題を修正する必要があります。
  • 本番環境の準備ができたら、データベースに変更を加えるには、デプロイされたJavaコードを変更するために必要な形式に加えて、いくつかの追加の形式が必要になる可能性があります。
  • 考慮すべきもう1つの重要な問題は、データベースに依存しないことです。さまざまな種類のデータベースで動作する製品を構築している場合、さまざまなバージョンのストアドプロシージャを作成する必要があり、維持するコードが増えます（デバッグ、バグ修正）。 、変更など）。
  • これは、さまざまな（可能性はあるが未知の）クライアントのさまざまな環境に展開する予定の製品を構築している場合に非常に重要です。RDBMSが何を使用するかを予測することはできません。
  • ORMフレームワーク（Hibernate、EclipseLink）を使用する場合は、かなり最適化されたクエリが生成されます。さらに、ストアドプロシージャを使用すると、後で統合するのがより困難になります。
  • 適切な量​​のロギングを使用すると、最適化の目的でクエリを簡単に分析できます。JDBCロギングまたはORMプロバイダーによって提供されるロギングを使用して、クエリがアプリケーションによってどのように使用されているか、回数、頻度などを実際に確認し、重要な場所を最適化できます。
于 2012-06-10T19:46:34.080 に答える