一時テーブルの基本構造とスコープ

SQL Serverでは、ストアドプロシージャ内で中間データを保持するために一時テーブルが頻繁に使用されます。特に医療情報システム（HIS）のようなレガシーシステムでは、複数の一時テーブルを連続して生成する設計がよく見られます。これは現代のアプリケーション開発スタイルとは異なるため、その背景や利点・課題について検討する必要があります。

一時テーブルはtempdbデータベース内に作成され、セッションまたはプロシージャのライフサイクルに紐づいて管理されます。主に以下の2種類があります：

• ローカル一時テーブル（#table_name）：現在のセッションでのみ可視。ストアドプロシージャ内で作成された場合、プロシージャ終了時に自動削除されます。
• グローバル一時テーブル（##table_name）：すべてのセッションからアクセス可能。作成したセッションが終了すると削除されますが、他のセッションが参照中の場合はその参照が解放されるまで保持されます。

制約事項

一時テーブルにはいくつかの技術的制限があります：

• 名前長は最大116文字まで（内部的にシステムがサフィックスを追加するため）。
• tempdbに依存するため、カスタムデータ型やXMLスキーマコレクションは明示的にtempdbに登録されていない限り使用不可。
• パーティショニングや外部キー制約の定義がサポートされていない。
• インデックスやCHECK制約は付加可能だが、名前を明示するとセッション間で競合する可能性がある。そのため、制約名を省略してシステムが自動生成させる方が安全です。

一時テーブルの生成方法

以下のように2通りの方法で作成できます：

-- 方法1: CREATE TABLE を使用
CREATE TABLE #PatientSummary (
    PatientID INT PRIMARY KEY,
    VisitCount INT,
    LastVisitDate DATETIME
);

-- 方法2: SELECT INTO を使用（データと共に作成）
SELECT 
    p.PatientID,
    COUNT(v.VisitID) AS VisitCount,
    MAX(v.VisitDate) AS LastVisitDate
INTO #PatientSummary
FROM Patients p
LEFT JOIN Visits v ON p.PatientID = v.PatientID
GROUP BY p.PatientID;

また、ストアドプロシージャの結果を直接一時テーブルに挿入することも可能です：

INSERT INTO #PatientSummary EXEC GetPatientStatistics @Year = 2023;

使用上の利点

• 複雑なクエリの分割が可能：巨大なJOINやサブクエリを複数の段階に分け、途中経過を保持できるため、論理構造が明確になります。
• 再利用性の向上：一度集計した結果を複数の後続クエリで参照でき、重複処理を回避できます。
• ロック時間の短縮：元のテーブルに対する長時間の読み取りロックを避けられ、並列処理への悪影響を軽減できます。

パフォーマンスとリスク

一時テーブルは有用ですが、以下の点に注意が必要です：

• tempdb の負荷集中：多数のプロシージャが同時に一時テーブルを作成・削除すると、tempdbのメタデータ競合やIOボトルネックが発生します。
• メモリとディスク使用量：大量データを格納すると、サーバーリソースを圧迫し、全体的な応答性が低下します。
• 高スループット環境との不適合：Web系アプリケーションのように多数の同時接続が予想される場合、一時テーブルの乱用はスケーラビリティの障壁になります。

代替手段の検討

近年では、次のような手法が推奨されています：

• メモリ最適化一時テーブル：In-Memory OLTP機能を利用し、tempdbではなくメモリ上に配置することで高速化が図れます。
• CTE（共通テーブル式）：単純な中間結果については、一時テーブルを使わずCTEで済ませる方が効率的な場合が多いです。
• テーブル変数：小規模データ向け。統計情報を持たないため大規模データには不向きですが、tempdbのログ負荷を低減できます。

結論

一時テーブルは、特に集計処理の多いバッチ指向のシステムにおいて依然として有効なツールです。しかし、クラウドやマイクロサービス指向のアーキテクチャへ移行する際には、その使用頻度を見直す必要があります。特にインターネット対応のHISシステムでは、リソース消費の少ない設計への刷新が求められます。