いくつかの複雑な基本的な関連付けを持つWebアプリを作成しています。いくつかの問題を解決するために、UNIONビューを作成してもらいました。これを解決できる方法は他にもたくさんあるでしょう。
しかし、現在、設計の効率を検討しているので、VIEWが照会されるたびに新しく作成されるのか、それとも1回だけ作成され、更新され続けるのかを知りたいと思いました。
詳述すると、table_a（100レコード）とtable_b（100レコード）があり、UNIONビューを作成すると、200レコードのビューが作成されます。
このプロセス全体は、ビューに対して選択を行うたびに発生しますか？
繰り返しますが、明らかに、基になるテーブルレコードを更新するたびにビューが更新されますが、ビューはこの1つのレコードを更新しますか、それともビュー全体を最初から再作成しますか？
デール
ビューは、名前を持つクエリにすぎません。クエリプランの再利用、キャッシュされたアクセス制御など、一部の DBMS が他の DBMS よりも優れている (pgSQL の方が優れているようです) パフォーマンス関連の最適化が考えられます。
ただし、1 日の終わりには、ほとんどの場合、SQL を直接発行するようにビューが動作することを期待できます。基になるテーブルへのアクセスを許可せずに、このクエリへのアクセスを許可できるという違いがあります。
動作を変更する（半分テーブルのようにする）ことができる最適化があり、マテリアライズドビューのようにpgSQLに存在する場合と存在しない場合があります（pgSQLについては申し訳ありません）が、これは単なるつまらないものです。
EXPLAIN を使用して VIEW がどのように実行されるかを確認すると、通常のクエリと同じ結果が得られます。
EXPLAIN
SELECT * FROM name_of_your_view WHERE foo = 23;
PostgreSQL は、ビューを結合したり、他のビューを使用するビューを持ったりする場合でも、内部クエリを最適化しようとします。オプティマイザーがその (素晴らしい) 仕事を行う前に VIEW を実行する必要がある状況を避けるようにしてください。集計、ORDER BY、および LIMIT は、ネストされたビュー内で使用する場合の潜在的な問題の例です。EXPLAIN を使用して、何が起こっているかを確認してください。
このプロセス全体は、ビューに対して選択を行うたびに発生しますか？
はい。
非マテリアライズドビュー（PostgreSQLはマテリアライズドビューをサポートしていません）は、準備されたSQLステートメントです。ビュー参照を、ビューの基になっているSELECTを含むサブクエリに置き換えることで同じパフォーマンスが得られます。
これが、ビューでクエリを実行するたびにサポートテーブルに基づく値が表示される理由です。ビューを更新せずに列操作がPostgreSQLで表示されるかどうかはわかりません-IE：SELECT*FROMに基づいてビューを作成する場合table_xをクリックしてから、table_xから列を追加または削除します。ほとんどのデータベースでは、ビューを更新して、ビューを介してその変更を確認する必要があります。
ビューの上にビューを構築することはお勧めできません。それらは脆弱です。問題があるかどうかは、別のビューに依存して実行するまでわかりません。そして、パフォーマンスの向上はありません-むしろその逆です。コードの再利用は、SETベースの環境ではうまく機能しません...