MySQL ビューは複雑なクエリよりも効率的ですか?

Question

複数の内部結合を使用する SELECT ステートメントに問題があります。私のコードは次のとおりです:

リーリー

INNER JOIN を使用して映画の俳優とその俳優が演じた役割を取得することは機能するようですが、映画の種類を取得するための最後の 2 つの結合が機能しないため、それらをビューに書き込めると考えました。結果を出力する場合はそれらが結合されます。したがって、最終的に 3 つのビューが得られます。 1 つはジャンル、俳優、役割を取得し、もう 1 つはすべてをまとめます。問題は、これが 1 つの大きな SELECT ステートメントと複数の接続を使用するよりも優れているのかということです。

クエリを何度も書き直して、さまざまな方法で試してみました

Answer 1

ビューを含むクエリを実行すると、MySQL/MariaDB のクエリ プランナーは、テーブルへのアクセス方法を決定する前に、すべてのビューとメイン クエリを 1 つのクエリに結合します。したがって、ビュー、 パブリック式 、および/またはサブクエリを使用する場合、 パフォーマンスは本質的に同じ になります。

言い換えれば、ビューはクエリの複雑さをカプセル化するのに便利な方法です。

また、部分的に信頼されたユーザーに、基礎となるテーブルへのアクセスを許可せずに、ビューへのアクセスを許可することもできます。

ビューの欠点は、アプリケーションの代わりにデータベース管理システムにアプリケーション ロジックを組み込む場合の欠点と同じです。つまり、更新が難しくなり、更新を忘れやすくなります。 (アプリケーション コードが更新されたときにビュー、ストアド関数、ストアド プロシージャを更新する信頼性の高いアプリケーション更新ワークフローがある場合、この質問は関係ありません。)

とはいえ、このタイプのクエリを記述する良い方法は、「トップレベル」エンティティを含むテーブルから始めることです。あなたの場合、それは映画だと思います。次に、INNER JOIN を使用する代わりに LEFT JOIN を使用して他のテーブルを結合します。こうすることで、一部のサブエンティティ (俳優、ジャンルなど) が欠落している場合でも、結果に映画を表示できます。

プロのヒント: 可能であれば、whatever01、whatever02## を使用する代わりに、テーブルに含まれるエンティティ (映画、ジャンル、俳優など) の名前をテーブルに付けます。 # クラスの名前。クエリを見てその理由を理解できることが重要であり、テーブル名を使用するとこれが簡単になります。