計算列とは、テーブル内の他の列に基づいて自動的に生成される値を持つ列です。この概念は、各クエリに式を繰り返すことなく、代表的な計算の結果にアクセスすることを簡素化するために導入されました。これらは、仮想列（値は毎回の選択時に計算される）または永続列（データが更新されるときに物理的に保存される）として宣言できます。

問題は、すべての式がテーブルレベルで計算できるわけではないこと（関数の種類に制限がある）、また、派生データの物理保存がスペースを占有し、UPDATE時に最新性を維持する必要があることです。

解決策：可能な場合はDDLレベルで計算列を宣言するか、保存が必要な場合はトリガー/プロシージャを通じて更新ロジックを実装するか、または集計を使用します。

コードの例（MS SQL Server）：

ALTER TABLE orders ADD total_sum AS (quantity * price); -- 仮想列
ALTER TABLE orders ADD total_sum_persisted AS (quantity * price) PERSISTED; -- 永続列

主な特徴：

仮想列は冗長性を減らしますが、選択の速度が低下します。
永続列は自動的に更新されますが、スペースとリソースを消費します。
一部の式は禁止されています：計算列内で複製できない関数やサブクエリを使用することはできません。

トリックの質問

計算列にインデックスを作成できますか？

列がPERSISTED（物理的に保存される）として宣言されている場合は、インデックスを作成できます。仮想列の場合は、必ずしもそうとは限らず、データベースシステムによります。

CREATE INDEX ix_total_sum ON orders (total_sum_persisted);

元の列が変更されたときに計算列は自動的に更新されますか？

はい、元のデータを挿入または編集すると、計算列は自動的に新しい値を計算されます。列がテーブルレベルで計算列として宣言されている場合のみです。

計算列がNULLを参照している場合はどうなりますか？

ほとんどのデータベースは、オペランドのいずれかがNULLの場合、NULLを返します。COALESCE/ISNULLを介して可能なNULL値を必ず処理してください。

ALTER TABLE orders ADD total_with_discount AS (COALESCE(quantity * price, 0));

一般的なエラーとアンチパターン

不要に重複した派生値を保存することは、ボリュームを増加させます。
複雑でインデックス化できない式を使用することは、パフォーマンスを低下させます。
アプリケーションレベルで計算が行われる場合、一貫性のない更新が発生します。

実生活の例

ネガティブケース

データベースには、商品金額と価格が別々のフィールドとして保存され、合計が別に保持されています。商品を更新するときに合計を更新することを忘れます。

利点：

読み込みが速い

欠点：

データの不整合、再計算の難しさ。

ポジティブケース

最終合計が仮想列として宣言されています。常に正確で、元の値と一致します。