3

私の質問は非常に単純で、タイトルにあります。Google とスタック オーバーフローでは何も得られないので、質問する時が来たと考えました。

現在、ユーザーがサイトに登録するときの SQL クエリを作成中です。私は常に呼び出し可能ステートメントの余分なコーディングのために準備済みステートメントのみを使用してきましたが、通常のステートメントのパフォーマンスへの影響は両方ともオフになっています。ただし、このクエリにより、以前の 1 つのサイズがすべての (準備されたステートメント) に適合する方法に代わる可能性のある方法を考えさせられます。

このクエリには、データベースへの合計 4 回の往復があります。手順は次のとおりです。

  1. ユーザーをデータベースに挿入し、結果セット内で生成されたキー (ユーザー ID) を取得します。
  2. ユーザー ID を取得して、album テーブルに行を挿入します。生成されたキー (アルバム ID) を取得する
  3. アルバム ID を取得し、images テーブルに行を挿入します。生成されたキー (イメージ ID) を取得する
  4. イメージ ID を取得し、ユーザー テーブルの現在のデフォルト列をイメージ ID で更新します。

余談ですが、挿入後にキーを取り戻す方法に興味がある人は、Statement.RETURN_GENERATED_KEYSこれに関する素晴らしい記事をここで読むことができます - IBM Article

とにかく、4つのラウンドトリップ（ただしキャッシュ可能）の準備済みステートメントの使用が問題ないかどうか、またはバッチ化された（ただしキャッシュ可能ではない）ステートメントを使用する必要があるかどうかを知りたいですか？

4

3 に答える 3

1

パフォーマンスを向上させ、データベースのラウンドトリップを減らすために、dasblinkenlightとajdukeに同意します。ストアドプロシージャがこれを実現します。

しかし、これは本当にアプリケーションのパフォーマンスのボトルネックですか？

  • ユーザーはどのくらいの頻度でサイトに登録しますか？
  • これを、これらのテーブルから情報が読み取られる頻度と比較してください（ページアクセスごとに1回？）

これらのテーブルの情報が、新しい登録を介して書き込まれるよりも何千倍も読み取られている場合は、ストアドプロシージャのアプローチを採用する価値がない可能性があります。

ストアドプロシージャを使用せず、準備されたステートメントに固執したくない理由：

  • プリペアドステートメントを使用するほど移植性はありません（データベースごとに異なる構文/言語、一部の単純なデータベースはそれらをサポートしていません）
  • JPA *などのORMソリューションでは機能しません-PreparedStatementsを直接使用すると述べたため、これはおそらく現在は当てはまりませんが、将来ORMを使用する場合は後で制限される可能性があります

* JPA 2.1は実際にはストアドプロシージャをサポートしている可能性がありますが、執筆時点ではまだリリースされていません。

于 2013-03-13T05:15:28.723 に答える
1

この 4 つの操作すべてを行う 1 つの Stored Proc を作成し、必要なすべてのパラメーターをアプリケーションから (ストアド プロシージャに) 一度に渡し、そこでストアド プロシージャに渡すことをお勧めします。結果セット用に生成されたキーを取得できます。

于 2013-03-13T04:50:43.640 に答える