SQLite | ゼロからはじめるSQL、30日で習得するSQLite：データ操作・設計 － Day23 ビュー

Day23 前半

「VIEW は“よく使う SELECT に名前をつけてテーブルみたいに扱う仕組み」だと思っていい

ここまで、
テーブルを設計して
SELECT / JOIN / サブクエリで
欲しい形の結果を作る、という流れをやってきました。

Day23 のテーマは ビュー（VIEW） です。

一言でいうと、ビューは

「よく使う SELECT に名前をつけて、
まるでテーブルのように扱えるようにしたもの」

です。

中身はあくまで SELECT 文ですが、
アプリや他の SQL からは

SELECT * FROM そのビュー名;

SELECT * FROM そのビュー名;

と書くだけで、
複雑な SELECT の結果を“テーブルっぽく”扱えます。

まずは「面倒くさい SELECT」を想像してみる

「毎回 JOIN と集計を書くのはダルい、を正直に認める」

次のようなテーブルを考えます。

users
id | name
---+-----------
1  | 山田太郎
2  | 佐藤花子

orders
id | user_id | amount
---+---------+-------
1  | 1       | 1200
2  | 1       | 3000
3  | 2       | 500

ここで、
「ユーザーごとの合計購入金額」をよく使うとします。

そのたびに、こんな SELECT を書くのは正直しんどいです。

SELECT
  u.id,
  u.name,
  SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o
  ON u.id = o.user_id
GROUP BY u.id, u.name;

SELECT
  u.id,
  u.name,
  SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o
  ON u.id = o.user_id
GROUP BY u.id, u.name;

ダッシュボード
管理画面
バッチ処理

など、あちこちで同じような SELECT を書くと、
コピペだらけになり、
どこか一箇所だけ修正漏れ、という事故も起きやすくなります。

ここで出てくるのが VIEW です。

VIEW の基本イメージ

「SELECT に“仮想テーブル名”をつける」

さっきの SELECT に、
user_totals という名前をつけてビューを作ってみます。

CREATE VIEW user_totals AS
SELECT
  u.id,
  u.name,
  SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o
  ON u.id = o.user_id
GROUP BY u.id, u.name;

CREATE VIEW user_totals AS
SELECT
  u.id,
  u.name,
  SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o
  ON u.id = o.user_id
GROUP BY u.id, u.name;

これで、user_totals というビューができます。

以降は、こんなふうに使えます。

SELECT * FROM user_totals;

SELECT * FROM user_totals;

結果は、さっきの SELECT と同じです。

id | name       | total_amount
---+------------+-------------
1  | 山田太郎   | 4200
2  | 佐藤花子   | 500

重要なのは、

ビューは「結果を保存しているテーブル」ではなく
「SELECT 文に名前をつけた“仮想テーブル”」

だということです。

SQLite のビューは、
呼び出されるたびに中の SELECT が実行されます。

VIEW を使うメリット①

「複雑な SELECT を“1つの名前”に隠して、SQL を短くできる」

一番分かりやすいメリットは、
単純に SQL が短くなる ことです。

ビューを作っておけば、

SELECT * FROM user_totals
WHERE total_amount >= 1000
ORDER BY total_amount DESC;

SELECT * FROM user_totals
WHERE total_amount >= 1000
ORDER BY total_amount DESC;

のように、
「合計金額が 1000 以上のユーザー」
といった条件を、
ビューに対する普通の SELECT として書けます。

もしビューがなければ、
毎回 JOIN と GROUP BY を書いたうえで
WHERE や ORDER BY を足すことになります。

ビューは、

「よく使う“中間結果”に名前をつけて、
そこからさらに絞り込んだり並べ替えたりできる」

という意味で、
SQL を分かりやすく分割する道具です。

VIEW を使うメリット②

「“正しい集計ロジック”を1か所に固定できる」

もう一つ大きいのが、
ロジックの一元化 です。

例えば、
「合計金額の定義」が途中で変わったとします。

送料を含める／含めない
キャンセル分を引く／引かない

など、現場ではよくある話です。

ビューを使っていない場合、
アプリのあちこちに散らばった SELECT を
全部探して修正しなければいけません。

ビューを使っている場合、

CREATE VIEW user_totals AS
SELECT ...

CREATE VIEW user_totals AS
SELECT ...

の中身を直すだけで、
user_totals を使っている全てのクエリに
新しい定義が自動的に反映されます。

これは、

「ビジネスロジックを1か所に集約する」

という意味で、
設計としてとても強いです。

VIEW の作り方の基本構文

「CREATE VIEW 名前 AS SELECT …」

構文自体はシンプルです。

CREATE VIEW ビュー名 AS
SELECT文;

CREATE VIEW ビュー名 AS
SELECT文;

さっきの例ならこうです。

CREATE VIEW user_totals AS
SELECT
  u.id,
  u.name,
  SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o
  ON u.id = o.user_id
GROUP BY u.id, u.name;

CREATE VIEW user_totals AS
SELECT
  u.id,
  u.name,
  SUM(o.amount) AS total_amount
FROM users u
LEFT JOIN orders o
  ON u.id = o.user_id
GROUP BY u.id, u.name;

ポイントは二つです。

ビュー名はテーブル名と同じルールで付ける（分かりやすく）
AS の後ろには、普通の SELECT をそのまま書く

ビューを作ったあとは、
テーブルと同じように

SELECT ... FROM user_totals;

SELECT ... FROM user_totals;

と書けます。

SQLite では、
ビューに対して INSERT / UPDATE / DELETE をするのは基本的に想定されていません
（単純なビューなら可能な場合もありますが、Day23 では「ビューは読む専用」と思っておいて大丈夫です）。

VIEW とセキュリティ

「見せていい列・行だけを切り出した“安全な窓”を作れる」

ビューは、
セキュリティの観点でもかなり強い武器 になります。

例えば、users テーブルに
パスワードハッシュや秘密情報が入っているとします。

users
id | name       | email             | password_hash | is_admin
---+------------+-------------------+---------------+---------
1  | 山田太郎   | taro@example.com  | ...           | 0

アプリの多くの画面では、

id, name, email だけ見えればよく、
password_hash や is_admin は
絶対に触らせたくない、という状況はよくあります。

このとき、ビューで
「見せていい列だけ」を切り出せます。

CREATE VIEW public_users AS
SELECT
  id,
  name,
  email
FROM users;

CREATE VIEW public_users AS
SELECT
  id,
  name,
  email
FROM users;

アプリ側は基本的に public_users だけを参照し、
生の users テーブルにはアクセスさせない、
という設計も可能です。

こうすると、

誤って password_hash を SELECT してしまう
といった事故を、構造的に防ぎやすくなります。

ビューは、

「テーブルの一部だけを、安全な“窓”として公開する」

という使い方ができる、
セキュリティ的にも重要な仕組みです。

小さな練習イメージ

頭の中で、次のような状況を想像してみてください。

ユーザーと注文テーブルがあり、
「ユーザーごとの合計購入金額」を
ダッシュボード・管理画面・レポートなど
あちこちで使っている。

このとき、

その SELECT を毎回書くのと、
user_totals というビューにしてしまうのとで、

どちらがミスが少なそうか
どちらが“定義変更”に強そうか

を比べてみると、
ビューの価値がかなりリアルに感じられるはずです。

Day23 前半のまとめ

ビュー（VIEW）は、「SELECT 文に名前をつけて、テーブルのように扱える“仮想テーブル”」だと捉えると分かりやすい。
CREATE VIEW 名前 AS SELECT … で作成し、その後は SELECT * FROM ビュー名 のように普通のテーブルと同じ感覚で参照できる。
よく使う複雑な SELECT（JOIN＋集計など）にビュー名を付けておくと、SQL が短くなり、ビジネスロジックを1か所に集約できる。
ビューを使えば、「見せていい列だけ」「特定の条件で絞った行だけ」を公開する“安全な窓”を作れるため、セキュリティ設計とも相性が良い。

後半では、

ビューを重ねて使うときの注意点
パフォーマンスと実行タイミング（“中身は毎回 SELECT”という話）
ビューとテーブルの役割の違い、いつビューにするかの判断軸

まで踏み込んで、「なんとなく便利そう」から「設計の道具として使える」レベルに持っていきます。