質問
ビューを作成すると、基本的に新しいテーブルを作成しています。これは、結合するテーブルの1つのデータが変更されたときに自動的に取引されます。あれは正しいですか?
また、なぜ私の見解ではサブQueriesを使用できないのですか?
解決
ビューが機能します テーブルのように, 、しかし、それはテーブルではありません。それは決して存在しません。ビュー名を参照するときに実行されるのは、準備されたSQLステートメントのみです。つまり:
CREATE VIEW foo AS
SELECT * FROM bar
SELECT * FROM foo
...実行に相当します:
SELECT x.*
FROM (SELECT * FROM bar) x
mysqldumpには、ビューに挿入される行が含まれていません...
また、なぜ私の見解ではサブQueriesを使用できないのですか????
それは、悲しいことに、(疑わしいとはいえ)デザインによるものです。 MySQLビューには多くの制限があります。これらは文書化されています。 http://dev.mysql.com/doc/refman/5.0/en/create-view.html
それで、それが単なる想像上のテーブル/準備されたステートメントである場合、それは理論的には通常のテーブル/クエリと同じパフォーマンス(またはさらに少ない)を持っていることを意味しますか?
いいえ。
テーブルにはインデックスが関連付けられているため、データ取得をより速くすることができます(挿入/更新のコストで)。一部のデータベースは、インデックスを適用できるビューである「具体化された」ビューをサポートしています。 サポートしていません 限られたビュー機能(V5 IIRCでのみ開始され、ゲームが非常に遅れた)を考えると。
ビューは派生テーブルであるため、ビューのパフォーマンスは、それが構築されているクエリと同じくらい良いです。そのクエリが吸うと、パフォーマンスの問題は雪だるま式になります...それは、ビューをクエリするときに言った - Where句のビュー列参照が関数に包まれていない場合(つまり:つまり: WHERE v.column LIKE ...
, いいえ WHERE LOWER(t.column) LIKE ...
)、オプティマイザーは、基準(述語と呼ばれる)を元のクエリに押し込むことができ、より速くなります。
他のヒント
私も同じ問題に遭遇しました(驚いたことに、私の検索はOracleとMSがそれをサポートしていることを示しているようです)。
私は、最終的なビューのために2つの追加ビューを作成することで、この制限を(少なくとも今のところ、使用できないことが証明されるまで)回避します。
例:
CREATE VIEW Foo1 AS
SELECT * FROM t ORDER BY ID, InsertDate DESC
CREATE VIEW Foo2 AS
SELECT * FROM Foo1 GROUP BY ID
CREATE VIEW Foo AS
SELECT * FROM Foo2 ORDER BY ID
上記の例には、基本的にテーブル「t」があり、これはすべての改訂を含む時間テーブルです。私の「foo」(ビュー)は、基本的に、各レコードの最新の改訂のみの単純なビューです。とりあえず大丈夫だと思われます!
アップデート:
これがMySQL 5.1の別のバグであるかどうかはわかりませんが、上記の例は実際には機能しません! 「Foo1」は予想どおりに機能しますが、「Foo2」はグループ化する前に順序を無視しているようであるため、最終結果は意図されていないものではありません。 「ASC」の「DESC」を変更すると同じ結果が得られます(驚くべきことに)。
また、あなたが読むなら 17.5.1。構文を表示します セクション、それは明確に述べています:
「ビューは、さまざまな種類の選択されたステートメントから作成できます。ベーステーブルやその他のビューを参照できます。結合、ユニオン、サブクエリを使用できます。」
データベースを5.6に更新して、もう一度試してみます!
違いは次のとおりです。
ビューのために、あなたはどこでサブ征服を持っていることができます - 部分、fromではなく - パーツ
CREATE VIEW v AS SELECT * FROM foo WHERE id IN (SELECT id FROM bar)
動作する - しかし同時に、読み取り専用ビューが表示されます...単一のテーブルの単純なビューは、基礎となるテーブルのビューを介して更新することができます