複雑怪奇なサブクエリを支配する：QueryDefによる動的SQL構築の「極意」
Access開発において、クエリを「コードの海」に漂流させていないだろうか。`DoCmd.RunSQL`や`CurrentDb.Execute`に、結合演算子`&`で繋いだスパゲッティ文字列を放り込むのは、プロの仕事ではない。
特にサブクエリが多層に重なる複雑なSQLを扱う際、インデントが崩れた文字列は「書いた本人すら読めない」技術的負債となる。今回は、QueryDefを駆使し、可読性とパフォーマンスを極限まで高めるアーキテクチャ論を説く。
—
1. SQL構築における「インデント」は単なる装飾ではない
SQLは実行エンジン（Jet/ACE）に対する「命令書」だ。命令書が乱雑であれば、エンジンは解析コストを余計に支払う。メンテナンス性を確保するための鉄則は、「SQLをコード上の文字列として構造化する」ことにある。
メンテナンス性を最大化する構築法
VBAでSQLを記述する際、私は常に `String` 変数への蓄積と、明示的な改行コード（`vbCrLf`）の挿入を徹底する。
Public Function BuildComplexQuery(ByVal targetID As Long) As String
Dim sql As String
‘ インデントを視覚化し、階層構造を直感的に把握できるようにする
sql = “SELECT T1.ID, T2.Summary ” & vbCrLf & _
“FROM (” & vbCrLf & _
” SELECT FROM RawData WHERE Status = 1″ & vbCrLf & _
“) AS T1” & vbCrLf & _
“INNER JOIN (” & vbCrLf & _
” SELECT ParentID, SUM(Amount) AS Summary FROM Details GROUP BY ParentID” & vbCrLf & _
“) AS T2 ON T1.ID = T2.ParentID ” & vbCrLf & _
“WHERE T1.ID = ” & targetID
BuildComplexQuery = sql
End Function
単に結合するのではなく、`vbCrLf` を挟むことで、デバッグ時に `Debug.Print` した際、Management Studioやクエリデザイナにそのままコピペして実行可能な美しいコードが生成される。これが現場の「標準」であるべきだ。
—
2. QueryDefとパラメーターの真実
動的SQLにおいて、文字列結合による値の埋め込みはSQLインジェクションの脆弱性を招く。シニアエンジニアは、`QueryDef` の `Parameters` コレクションを正しく使う。
Public Sub ExecuteParameterizedQuery(ByVal targetID As Long)
Dim db As DAO.Database
Dim qdf As DAO.QueryDef
Set db = CurrentDb
‘ 既存のクエリ定義を再利用、あるいは一時的に作成
Set qdf = db.QueryDefs(“tmp_AnalysisQuery”)
‘ パラメータを明示的にバインド（型安全性を確保）
qdf.Parameters(“prmTargetID”) = targetID
‘ 実行とオブジェクト解放
qdf.Execute dbFailOnError
‘ 明示的解放はVBAにおいて「礼儀」である
qdf.Close
Set qdf = Nothing
Set db = Nothing
End Sub
この手法の利点は、「コンパイル済みクエリ」としての実行計画がキャッシュされる可能性があることだ。頻繁に呼び出されるサブクエリを伴う処理では、この微差がミリ秒単位のパフォーマンス改善に直結する。
—
3. メモリ管理とレガシー環境の最適化
Accessのメモリ管理は一見自動的に見えるが、複雑なオブジェクト生成を繰り返すと、メモリリークの温床になる。
- DAOの明示的解放: `Set qdf = Nothing` を怠らないこと。これは単なるおまじないではない。Accessのガベージコレクションに頼るのではなく、スコープを抜ける前にメモリを解放する意識が、大規模システムにおける「落ちないアプリ」を作る。
- Windows APIの活用: 大規模なデータ処理を行う際、Accessの内部バッファだけでは非力な場合がある。`GlobalAlloc` や `MoveMemory` を駆使し、メモリマップドファイル経由でデータをやり取りする手法も、極限のパフォーマンスを求めるならば視野に入れるべきだ。
—
4. チーフアーキテクトからの助言
サブクエリが深いSQLに遭遇したら、まず自問してほしい。「これは本当にAccessのクエリだけで完結すべきか？」と。
サブクエリが4階層を超える場合は、コードでSQLを組み立てるのではなく、「一時テーブル」を活用することを強く推奨する。
1. ステップ1：前処理を一時テーブルに書き出す。
2. ステップ2：その一時テーブルをクエリのソースにする。
複雑なSQLは「解析時間」を増大させ、デッドロックのリスクを高める。一時テーブルを介した段階的な処理は、デバッグ効率においてSQL構築の苦労を遥かに凌駕する。
結びに代えて
VBAはレガシーではない。使い手の「作法」がレガシーなだけだ。
コードのインデント、オブジェクトのライフサイクル管理、そして「なぜその書き方をするのか」という思想。これらを突き詰めた先に、Accessというフレームワークの限界を超えた、堅牢なシステムが立ち上がる。
明日の開発では、単に「動くコード」ではなく、「誰が読んでも意図が伝わる、無駄のない構造」を書いてほしい。それが、プロのエンジニアとしての責務だ。
