はじめに
計測データを扱うシステムでは、
次のような構成になることがよくあります。
- 5分ごとの生データ
- 1時間ごとの集計データ
- データソース都合で分かれた複数テーブル
これらをアプリケーションから扱うとき、
「同じ形式として扱いたい」
と考えるのは自然です。
その際によく出てくる選択肢が VIEW + UNION です。
本記事では、
- UNION を使う設計が 良いケース
- アンチパターン になるケース
- 設計時の判断軸
を、計測データを例に整理します。
想定する前提
- 計測データを保持するテーブルが複数ある
- カラム構成はほぼ同じ
- 違いは以下のいずれか
- 粒度が異なる（例えば、5分 / 1時間）
- 生データ / 集計済み
- データソースの違い
- アプリケーションからは「同じ形式」で参照したい
結論
参照・集計用途であれば、VIEW + UNION は筋が良い
ただし、
「同じ形」ではなく「同じ意味で扱って安全か」
を満たしていないと、簡単にアンチパターンになります。
良い例：Read Model としての UNION VIEW
実体テーブル
measurement_5min
----------------------
timestamp
value
measurement_hourly
----------------------
timestamp
value
VIEW
CREATE VIEW v_measurements AS
SELECT
timestamp,
value,
5 AS interval_minutes,
'raw' AS aggregation_type
FROM measurement_5min
UNION ALL
SELECT
timestamp,
value,
60 AS interval_minutes,
'hourly_avg' AS aggregation_type
FROM measurement_hourly;
ポイント
- 粒度・集計状態を 列として明示
- 実体テーブルの差異を VIEW に閉じ込めている
- VIEW は 参照専用（Read Model）
アンチパターン①：意味が違う値を同列で UNION
❌ 問題のある設計
measurement_5min
----------------------
timestamp
temperature -- 実測値
measurement_hourly
----------------------
timestamp
temperature -- 1時間平均
CREATE VIEW v_measurements AS
SELECT timestamp, temperature FROM measurement_5min
UNION ALL
SELECT timestamp, temperature FROM measurement_hourly;
何が問題か
- 列名は同じだが 意味が違う
- 利用者が区別できない
SELECT AVG(temperature) FROM v_measurements;
👉 生データと平均値が混ざった 意味不明な集計 が生まれる
アンチパターン②：粒度情報を持たせていない
CREATE VIEW v_measurements AS
SELECT timestamp, value FROM measurement_5min
UNION ALL
SELECT timestamp, value FROM measurement_hourly;
問題点
- timestamp = 10:00 が何を意味するか分からない
- 時系列分析で歪みが発生
👉 時間軸を信用できない VIEW になる
アンチパターン③：書き込み対象にしようとする
INSERT INTO v_measurements (...)
問題点
- どの実体テーブルに入るか決まらない
- トリガー依存・実装不能
👉 UNION VIEW は Write Model にしてはいけない
アンチパターン④：万能 VIEW を作ろうとする
v_measurements_all =
5分 + 1時間 + 日次 + 月次
問題点
- 将来の拡張で肥大化
- パフォーマンス劣化
- 影響範囲が読めない
👉 用途別 VIEW が基本
設計時のチェックリスト
UNION VIEW を作る前に、次を確認します。
- UNION した結果をそのまま集計しても意味が破綻しないか
- 粒度・集計状態が列として表現されているか
- VIEW は参照専用になっているか
- 将来の粒度追加を想定しているか
1つでも怪しければ、設計を見直した方が安全です。
まとめ
- UNION + VIEW は 論理モデルの統合手段
- 「便利だからまとめる」は危険
- 意味・粒度・用途を明示することが最重要
UNION する基準は「同じ形」ではなく「同じ意味」
計測データ設計では特に、この意識がないと事故ります。
おわりに
本記事では UNION を中心に整理しましたが、
- 縦持ち / 横持ち
- Read Model / Write Model
- 集計データの扱い方
とも強く関係します。
これらを分けて考えると、データ設計で迷うことが一気に減ります。