35

MySQL がストアド プロシージャのサポートを開始して以来、私はそれらを実際に使用したことはありません。理由の 1 つは、私が優れたクエリ ライターではないことと、DBA と一緒に仕事をすることが多いためです。DBA は、私に代わってそれらの選択を行います。また、私が知っていることだけに満足しているからです。

データ選択の実行に関して、特に本質的に非正規化 (結合) および集計 (平均または最大、サブクエリ w/カウントなど) である選択を検討する場合、MySQL 5.x で正しい選択は何ですか? ? ビュー？それともストアドプロシージャ？

私が快適に使用できるビュー - SELECT クエリがどのように見えるかを知っているので、それを作成し、インデックスが作成されていることを確認してから、CREATE VIEW [View] AS SELECT [...]. 次に、私のアプリケーションでは、ビューを読み取り専用テーブルとして扱います。これは、正規化されたデータの非正規化バージョンを表します。

ここでの欠点は何ですか - もしあれば？また、まったく同じ SELECT ステートメントをストアド プロシージャに移動すると、何が変わるでしょうか (利益または損失)。

このトピックをグーグルで検索しているときに見つけるのが困難だった、いくつかの良い「ボンネットの下」の情報を見つけたいと思っていますが、本当にすべてのコメントと回答を歓迎します.

4

4 に答える 4

13

私の意見では、ストアド プロシージャは、複数の異なるアプリケーション間で同じルーチンを使用する必要がある場合、またはデータベースまたはテーブル間の ETL のためにデータ操作にのみ使用する必要があります。基本的に、DRY 原則に遭遇するか、DB 内のある場所から別の場所にデータを移動するだけになるまで、できる限り多くのことをコードで行います。

ビューを使用して、データに代替または単純化された「ビュー」を提供できます。そのため、データを表示する別の方法を見つけるほど実際にはデータを操作していないので、ビューを使用します。

于 2009-03-25T17:16:08.807 に答える
7

どちらかまたは両方の選択かどうかはわかりません。ストアド プロシージャは、ビューが苦労するさまざまなことを行うことができます (一時テーブルにデータを入力し、その上でカーソルを実行し、集計を行って結果セットを返すことを考えてみてください)。

一方、ビューは複雑な sql/アクセス権を隠し、スキーマの変更されたビューを提示できます。

どちらも物事のスキームの中で場所を占めており、どちらもスキーマの実装を成功させるのに役立ちます。

于 2009-03-25T17:18:27.490 に答える
6

非正規化または出力フォーマット用のビューと、フィルタリングおよびデータ操作（パラメーター入力を必要とするもの）または反復（カーソル）用のストアドプロシージャを使用します。

非正規化とフィルタリングの両方が必要な場合、ストアドプロシージャ内のビューにアクセスすることがよくあります。

于 2009-03-25T18:51:51.307 に答える
5

注意すべきことの 1 つは、少なくとも mysql ビューの結果は一時テーブルに格納され、ほとんどのまともなデータベース エンジンとは異なり、このテーブルはインデックス化されていないため、クエリを単純化するために使用する場合、プログラムがすべてのデータを取得するときにビューが最適です。ただし、そのビューの結果をパラメーターに基づいて検索すると、特にふるいにかけるレコードが何百万もある場合は非常に遅くなり、ビューが他のビューの上に構築されている場合はさらに悪化します。

ストアド プロシージャですが、これらの検索パラメーターを渡して、下線付きの (インデックス付き) テーブルに対して直接クエリを実行できます。欠点は、プロシージャを実行するたびに結果をフェッチする必要があることです。これは、サーバーの構成によってはビューでも発生する可能性があります。

したがって、基本的に、ビューを使用して結果の数を最小限に抑えようとする場合 (検索する必要がある場合)、それ以外の場合はストアド プロシージャを使用します。

于 2015-06-26T01:26:50.133 に答える