この時点まで、データベース構造の変更を回避することができたベンダー提供のデータベースがあります。間もなく、関連するプロジェクトについてテーブルに直接クエリを実行する予定です。必要なすべてのデータを取得するには、複数の和集合を持つ大きなSQLステートメントを作成する必要があります。
select ... from table1
union
select ... from table2
...
select ... from tableN
このプロジェクトではスピードが最優先事項です。結合を行うためのビューを作成してから、このビューをクエリする（したがって、ベンダーデータベースに変更を加える）か、アプリケーションからunionステートメントを実行する方が速いでしょうか？
ベンダーデータベースに変更を加えることに伴う潜在的な問題を知っているので、フィードバックを探しているのはなぜですか。
ビューは速くなりません（開発時間を除いて）。
それが機能する場合、より速いのはUNIONALLを使用することです。UNIONは重複したレコードを探し、それらを最終結果から削除します。設計によるレコード（各テーブルが異なるクリネット用である、または各テーブルの日付範囲が異なるなど）が複製できないことがわかっている場合、UNION ALLは結果セットを区別しようとしないため、はるかに高速に実行されます。
ベンダーデータベースに関しては、既存のテーブルに変更を加えることを非常に躊躇します。ビューのようなものを追加するのは、それを使用するのはあなただけなので、少し安全に思えます。ビューに関する私の最大の懸念は、DBに変更を加えた更新をベンダーから受け取ったことがあり、ビューが失われる可能性があるかどうかです。
インデックス付きのビューを使用しない限り、ビューを使用してもパフォーマンスが向上することはないと思います。残念ながら、ユニオンを使用して作成されたビューにインデックスを作成することはできません（少なくともSQL Serverでは）。
個人的には、ロジックをアプリケーションに配置するのか、DBに配置するのかということになると、私はDBに傾倒します。私の経験では、これらのタイプの変更は展開と保守が簡単です。
もし私があなたの状況にあったら、それがあなたの人生を楽にするなら、私は先にビューを作成します。しかし、繰り返しになりますが、パフォーマンスの向上は期待しないでください。