基本情報技術者 2009年 春期 午前（科目A） 問31

ストアドプロシージャ利用【午前解説】

正解の理由

解法ステップ

1. ネットワーク往復が多い箇所をログやプロファイラで特定する（ホットスポット抽出）。
2. その箇所で発行される複数SQL文をまとめられるか検討する（まとめて一回で済ませる処理単位を定義）。
3. ストアドプロシージャで該当ロジックを実装し、パラメータで動的値を受け渡す形にする。
4. トランザクション境界や例外処理をサーバ側で適切に扱い、結果セットを必要最小限にする。
5. 比較測定（通信回数、往復時間、CPU/IO負荷）を行い、必要なら調整する。

選択肢別の誤答解説

• ア: インデックスの見直し
  インデックスはクエリ実行時間やI/Oを改善しますが、クライアントが発行するSQLの回数や通信往復を直接減らす手段ではありません。通信負荷が主因の場合は効果が限定的です。
• イ: ストアドプロシージャ機能の利用
  正解です。複数のSQLをサーバ内でまとめて実行し、クライアントとサーバ間のメッセージ往復と解析オーバーヘッドを削減できます。パラメータ化や結果の最小化で通信量も抑えられます。
• ウ: データベースの再編成
  再編成（再配置・再構成）は断片化解消やI/O改善に役立ちますが、クライアントとサーバ間のSQL発行頻度や通信回数そのものを減らす対策ではありません。
• エ: 動的SQLの利用
  動的SQLは柔軟性がありますが、文ごとの生成・パースが増えると往復や解析コストを増やし得ます。通信負荷を下げる逆効果になる可能性があります。

よくある誤解

• ストアドプロシージャは常に高速という誤解：ロジックが複雑すぎるとサーバ側の負荷や保守性が悪化します。
• インデックス調整で通信量が減ると考える誤解：インデックスは処理時間短縮に寄与しても、クライアントとサーバ間のSQL回数自体は減りません。
• 動的SQLは柔軟ゆえに通信負荷を下げると誤解：動的SQLは却って文数やパース負荷を増やすことがあります。

補足コラム

• ストアドプロシージャ以外の手法として「バッチ化」や「プリペアドステートメント」「結果キャッシュ」「接続プール／コネクションの再利用」も検討対象です。特にプリペアドステートメントは同一SQLの再利用でパースコストを抑える点で有効ですが、往復回数自体を削減するにはストアドプロシージャやバッチ化が優先されます。
• 運用面では、ストアドプロシージャを増やすとDB側にビジネスロジックが集中し、開発・テスト・デプロイのワークフローに影響します。CI、バージョン管理、アクセス権限の設計に注意してください。

# psycopg2 風の例（PostgreSQL のストアドプロシージャ呼出し）
conn = get_connection()
cur = conn.cursor()
cur.callproc("process_many_rows", [param1, param2])
result = cur.fetchall()
cur.close()
conn.close()

FAQ