0

ビューは、実際のテーブルとエンド ユーザーの間の仲介者としてどのように機能しますか? ビューが作成されたときに発生する内部プロセスは何ですか。つまり、ビューがテーブル上に作成されると、それはテーブルとエンド ユーザーの間に壁のように立っているのでしょうか? チェックオプションのみを使用して、ビューは実際のテーブルをどのように保護しますか? しかし、ユーザーがテーブルに直接挿入した場合、実際のテーブルを保護するにはどうすればよいでしょうか?

insert into **vw** values()彼/彼女が :を使用せずに:を使用している場合insert into **table_name** values()、テーブルは現在どのように保護されていますか?

4

2 に答える 2

4

非マテリアライズド ビューは、あらかじめパッケージ化された SQL クエリです。派生テーブル/インライン ビューと同じように実行されます。同じビューへの複数の参照は、参照ごとにビューに含まれるクエリを実行します。いいえ:

CREATE VIEW vw_example AS
  SELECT id, column, date_column FROM ITEMS

SELECT x.*, y.*
  FROM vw_example x
  JOIN vw_example y ON y.id = x.id

...次のように変換されます。

SELECT x.*, y.*
  FROM (SELECT id, column, date_column FROM ITEMS) x
  JOIN (SELECT id, column, date_column FROM ITEMS) y ON y.id = x.id

キャッシング

クエリが同一になるため、主な利点はキャッシュです。実行計画が既に生成されているため、後でクエリをより高速に実行できるようにするために、実行計画を含むクエリがキャッシュされます。キャッシングでは、多くの場合、大文字と小文字を区別するポイントまでクエリを同一にする必要があり、最終的に期限切れになります。

述語のプッシュ

もう 1 つの潜在的な利点は、多くの場合、ビューで「述語のプッシュ」が許可されることです。この場合、ビューで指定された基準を、オプティマイザーによってビューが表すクエリにプッシュできます。これは、結果セットを外部/最終クエリに提示するためにテーブルをスキャンするのではなく、クエリがテーブルを 1 回スキャンできることを意味します。 

SELECT x.*
  FROM vw_example x
 WHERE x.column = 'y'

...オプティマイザは次のように解釈できます。

SELECT id, column, date_column 
  FROM ITEMS
 WHERE x.column = 'y'

述語プッシュの決定は、オプティマイザのみが行います。ビューが使用するクエリと、適用される追加の基準に実際に依存しているだけで、開発者が決定を強制する能力については知りません。

非マテリアライズド ビューの一般的な使用に関する解説

悲しいことに、マテリアライズされていない SQL ビューが、クエリの記述を簡素化するためのカプセル化にすぎないことがよくあります。簡素化も推奨される方法ではありません。SQL は SET ベースであり、手続き型のアプローチを使用して適切に最適化することはできません。ビューを互いに重ねることも、推奨される方法ではありません。

更新可能なビュー

マテリアライズされていないビューも更新可能ですが、多数のテーブルを結合してビューを作成できるため、制限があります。更新可能な非マテリアライズド ビューでは、ユーザーは新しいレコードを挿入できなくなりますが、既存のレコードを更新することはできます。 ある程度のCHECK OPTION更新制限を適用するためにビューを作成するために使用されるクエリに依存しますが、何も起こらないことを保証するには十分ではありません。これは、不要な追加/編集/削除から保護するための唯一の信頼できる手段は、できればロールを介してユーザーに適切な権限を付与することであることを示しています。

于 2011-03-10T05:54:06.807 に答える
2

ビューはテーブルを保護しませんが、パーミッション ベースのテーブル保護スキームで使用できます。ビューは、テーブルにアクセスするための便利な方法を提供するだけです。ユーザーにテーブルではなくビューへのアクセスを許可すると、おそらくアクセスが大幅に制限されます。

于 2011-03-10T05:39:41.540 に答える