ビューとテーブルの違いと使い分け——迷ったときにどちらを選ぶべきか？
データ基盤の設計などを始めたばかりだと、「これはビューにすべきか、テーブルにすべきか？」と迷う場面が意外と多いですよね。
自分も調べるまではなんとなくのイメージで捉えていたのですが、実際はかなりの違いがありました。
ということで今回は、ビューとテーブルの違い・それぞれのメリット・使い分けの考え方をまとめてみます！
おまけとして両者の中間的な存在であるマテリアライズドビューについても触れますのでぜひ最後まで読んでみてください！
テーブル（Table）とは
まずはテーブルから触れていきますが、テーブルとはデータを物理的に保存するオブジェクトのことを指します。
イメージ的には実体があるデータという感じです。（実際にそこにある……みたいな）
INSERT や LOAD によってデータが実際にディスクに書き込まれ、クエリを実行するたびにそのデータが読み取られるという特徴を持っています。
▼実行イメージ
CREATE TABLE orders (
order_id INT,
customer_id INT,
order_date DATE,
amount DECIMAL(10, 2)
);
テーブルのメリット
テーブルを活用するメリットとしては以下のようなものがあります。
クエリが速い
データが実体として存在するため毎回計算し直す必要がなく、読み取りが高速。
処理コストを前払いできる
ETLやバッチ処理で事前に加工・集計しておくことで、分析クエリの実行コストを大幅に下げられる。
ビュー（View）とは
ビューはSELECT文に名前をつけたものです。
テーブルと異なりデータそのものは保存されておらず、ビューを参照するたびに定義されたSQLが実行されます。
（つまりテーブルとは真逆で実体を持たず、定義されたSQLによって参照される仮想テーブルのようなもの）
▼実行イメージ
CREATE VIEW v_orders_summary AS
SELECT
customer_id,
COUNT(*) AS order_count,
SUM(amount) AS total_amount
FROM orders
GROUP BY customer_id;
例えば、上記のビューを SELECT * FROM v_orders_summary で実行すると、内部では orders テーブルに対してSQLが実行されるといった形で処理が行われます。
ビューのメリット
常に最新のデータが得られる
参照のたびに元テーブルからSQLを実行するため、元データが更新されれば自動的にビューの結果も変わります。
複雑なSQLをシンプルに見せられる
何十行もあるJOINや計算ロジックをビューに閉じ込めることで、利用側は SELECT * FROM v_xxx の一行で済みます。再利用性が高く、クエリのメンテナンスも楽になります。
ストレージを使わない
実データを持たないため、ストレージコストがかかりません。試験的なロジックや一時的な集計定義を置くのにも向いています。
テーブルとビュー、どう使い分けるか
テーブル・ビューの比較
| 観点 | テーブル | ビュー |
|---|---|---|
| データの実体 | あり（物理保存） | なし（SQL定義のみ） |
| クエリ速度 | 速い | 元テーブル次第 |
| データの鮮度 | バッチ更新が必要 | 常に最新 |
| ストレージ | 使用する | 使用しない |
| 複雑なロジックの隠蔽 | △ | ◎ |
テーブルを選ぶべき場面
- 集計・加工済みのデータを高速に返したい（DWH・DM層など）
- 複数のジョブや利用者から頻繁に参照される
- 大量データを扱うため、毎回計算すると重い
ビューを選ぶべき場面
- 元テーブルが常に最新の前提で、参照側のバッチ更新のラグをなくしたい
- ロジックを一箇所に集約して再利用したい
- ストレージを節約したい、または試験的なロジックを定義したい
それぞれを見ていくと、例えば大量データを複数人で扱う場合はテーブルの方が望ましい、処理の複雑でないデータを常に最新の状態で見たい場合はビューの方がよさそう、といった形で状況に応じて使い分けるのがベストということが分かります。
第3の選択肢：マテリアライズドビュー（Materialized View）
マテリアライズドビューとは
一言でいうなら、SQLの実行結果をテーブルとして保持する仕組みです。
（まさにビューとテーブルの中間といった感じです）
ビューは前述の通り実体を持ちませんが、マテリアライズドビューはその実行結果をディスクに保存します。
つまり参照のたびにSQLを実行し直すビューと違い、保存済みの結果をそのまま返すため読み取りが高速というメリットがあります。
「ビュー」という名前はついているものの、「自動で更新されるテーブル」として捉えてもいいかもしれないです。
▼実行イメージ
CREATE MATERIALIZED VIEW mv_orders_summary AS
SELECT
customer_id,
COUNT(*) AS order_count,
SUM(amount) AS total_amount
FROM orders
GROUP BY customer_id;
ビュー・テーブルとの比較
| 比較項目 | ビュー | テーブル（バッチ更新） | マテリアライズドビュー |
|---|---|---|---|
| データ保持 | しない | する | する |
| 参照時の動作 | SQLを実行して返す | 保存データをそのまま返す | 保存データをそのまま返す |
| 処理速度 | 遅い（複雑なSQLほど） | 速い | 速い |
| データ鮮度 | 常に最新 | バッチ実行タイミング次第 | リフレッシュタイミング次第 |
| 主な用途 | ロジック抽象化・アクセス制御 | 集計・加工済みデータの提供 | 重い集計処理のパフォーマンス改善 |
上記を見ていただくと、「バッチでテーブルを更新するのと何が違うのか？」という疑問が出てくるかと思います。
最大の違いは、変化点のみを更新する高速リフレッシュ（Incremental Refresh）に対応している点です。
バッチ処理でも更新日時やフラグを使って差分更新を実装することは可能ですが、「変化したかどうか」を判定するロジックを自前で書く必要があります。
一方マテリアライズドビューは、製品によっては DB 側が差分管理を肩代わりしてくれるため、大量データの集計処理でも更新を高速に行える点が便利です（対応状況は製品によって異なるため、後述の注意ボックスを参照）。
注意点
とはいえ、データを最新に保つには定期的なリフレッシュが必要なためリフレッシュ前はデータが古い状態になっています。
リアルタイム性が求められる場面には向かないため、更新頻度と鮮度要件をあわせて検討してください。
まとめ
最後までご覧いただきありがとうございます！
今回の内容をまとめると、
- テーブルはデータを物理保存し、速度と安定性が強み
- ビューはSQLに名前をつけたもので、鮮度・再利用性・ストレージ節約が強み
- マテリアライズドビューは両者の中間で、重いクエリのキャッシュとして有効
といった形になりました。
それぞれ状況によってかなりパフォーマンスが変わってくるため、実務にあたっては「システム要件」や「データ特性」、「ユーザーの要件」を見極めたうえで何を使うかを考える必要があると思います。
実際にやってみないとつかめない部分もあるかと思いますが、この記事が参考になれば幸いです。
Discussion