ビューとデータの抽象化

レッスンを通じて、クエリ (特に複雑な JOIN や GROUP BY のような集計) が長くなり、ルールや計算が多くなり始めることに気づいたでしょう。

完成したクエリを心の中で保存して表示から隠し、それ以降はどう見ても DB の通常の「テーブル」であるかのように振る舞う方法があったとしたらどうでしょうか?

View の世界へようこそ。

ビューの作成

ビューは本質的には永続化された名前付き SQL クエリですが、「仮想」テーブルと同じように動作します。

CREATE VIEW user_spending AS
SELECT
  c.id,
  c.first_name,
  SUM(o.amount) as total_spent
FROM customers c
JOIN orders o ON c.id = o.customer_id
GROUP BY c.id;

終わり！これで、JOIN と GROUP BY を常にやり直す必要がなくなり、完全に通常のクエリを記述するだけで済みます。

SELECT * FROM user_spending WHERE total_spent > 100;
-- Postgres dietro le quinte richiamerà automaticamente la grande formula.

ビューと「リアルタイムデータ」

非常に一般的な誤解は、Views がデータを取得し、価格やランキングなどの合計を計算し、写真のような悲しい永続スナップショットを作成するという考えです。 間違いです（ほぼ常に）！デフォルトでは、ビューは 仮想です。SELECT にビューの名前を入力するたびに、Postgres はその正確なミリ秒での DB の状態に基づいてリアルタイム計算を実行することにより、バックグラウンドでリクエストをマージします。したがって、古いデータを読み取ることはありません。

それらは何のためにあるのでしょうか？

• シンプルさ: ビューは外部アプリを変更から保護します。フロントエンド チームが top_selling ビューからデータを読み取る必要があることを知っていれば、明日、トップセラーを引き出すために 3 つの中間リレーションを追加してデータベースを変更しても心配する必要はありません。
• セキュリティと分離: 巨大な DB では、ビューでユーザー データの一部を事前に選択して外部開発者から非表示にし、(たとえば) 実名をスクラブした分析のサブビューのみにアクセスを許可できます。

ビューの削除

テーブルと同様に、必要がなくなったら、DROP コマンドを実行します。

DROP VIEW user_spending;

試してみてください

ビューの呼び出し