1

の有用性がとても気に入りましたCREATE VIEW。たとえば、グローバル値と特定の値を取得COALESCE(post.publish, profile.publish)できるため、publishisの場合NULL、代わりにグローバル値が取得されます。

パフォーマンスと論理の両方の観点から私が少し興味を持っている部分は、これを既存のテーブルと一緒にどのように使用するかです。テーブルがあるとしましょう：

CREATE TABLE post (
    id INT,
    profile_id INT,
    name VARCHAR,
    publish ENUM('TRUE', 'FALSE') NULL
)

CREATE VIEW次のように実行するのが最善でしょうか:

CREATE VIEW post_info AS
SELECT post.*, COALESCE(post.publish, profile.publish) AS publish
FROM post
INNER JOIN profile
ON post.profile_id = profile.id

そして、場合にのみ使用するpost_infoかSELECT、または:

CREATE VIEW post_info AS
SELECT post.id, COALESCE(post.publish, profile.publish) AS publish
FROM post
INNER JOIN profile
ON post.profile_id = profile.id

そしてJOIN post_info、追加postのSELECT値が必要な場合は?

これに関するあなたの洞察と考えを共有してください。各ソリューションの長所と短所について、ご意見をお聞かせください。私が言及していないものになることもあります。

4

1 に答える 1

0

それは、ビューをどのように使用するかによって大きく異なります。MySQL がビューを参照するクエリを処理できる方法は 2 つあります。使用される方法は、ビュー宣言のALGORITHM句によって異なります。

より良い言い回しがないため、マニュアルを複製します。

の場合[ALGORITHM =] MERGE、ビューを参照するステートメントのテキストとビュー定義は、ビュー定義の一部がステートメントの対応する部分を置き換えるようにマージされます。

の場合TEMPTABLE、ビューからの結果は一時テーブルに取得され、ステートメントの実行に使用されます。

の場合UNDEFINED、MySQL は使用するアルゴリズムを選択します。

このMERGEアルゴリズムは通常、最終クエリの処理を高速化しますが、MySQL がそれを使用できない場合が多くあります (詳細については、リンクされたマニュアル ページを参照してください)。

したがって、答えは次のとおりです。ビューが で定義されてALGORITHM = TEMPTABLE おらず、ラッピングクエリがMERGEアルゴリズムの使用を妨げない場合は、 を含むバージョンとSELECT *余分な を含まないバージョンのJOIN方が優れています。

それ以外の場合、MERGEが使用されていない場合は、2 番目のソリューションの方が適している可能性があります。

補足として、あなたが言及したユースケースに対処するためのより良いオプションは、アプリケーションレイヤーに挿入時にpost.publish値を入力させ、ビューと同様に削除することです。または、テーブルに適切なトリガーを配置することで、同じ効果を得ることができます。profile.publishJOIN

于 2013-06-27T10:07:31.153 に答える