1

今回は、より一般的な質問を受けました。元のデータが定期的に更新される場合、データの加重集計にストアド プロシージャではなく複数のビューを使用する必要がありますか?

基本的に、より大きなトランザクション データベースから同じ種類のデータ (テーブル) をインポートすることによって定期的に更新されるローカルの MySQL データベースがあります。

ローカル データベースは、統計分析に使用されます。したがって、統計ソフトウェア パッケージで使用するために、ローカルでデータを非正規化 (基本的に集計) します。これまでは、ストアド プロシージャを使用していました。これは、重み付けスキーム (基本的には、変数で乗算される重みを含む他のテーブル) が有効になったときに、扱いやすい (そしてより明確に配置されている) と感じたからです。

ただし、ストアド プロシージャの欠点は、テーブルに新しいデータが入力されたときに、すべてを再度実行しなければならないことです。明らかに、私は DBA ではありません...ですから、当然のことを言うのをためらわないでください :) この種のシナリオを処理するための最良のアプローチは何ですか? SPまたはビュー？それともまったく違うもの？

事前に提案があればthx！

4

1 に答える 1

1

それは依存します（それは「一般的な」質問に対する一般的な答えですよね？:)）。トレードオフを評価して、ニーズに最適なソリューションを確認する必要があります。

ビューは基本的に (MySQL では) クエリの書き換えにすぎないため、ビューを使用すると、クエリが実行されるたびに集計/非正規化が実行されます。これにより、クエリが必要以上に遅くなる場合があります。また、手順が非常に複雑な場合、そのロジックをビューに入れようとするのは実際的ではないかもしれません。

ストアド プロシージャは作業を 1 回行うため、クエリが高速になります。ただし、更新は自動的に表示されません。したがって、答えは、データが変更される頻度、クエリが実行される頻度、およびクエリのパフォーマンスがどれほど重要であるかによって異なると思います。

別の提案として、データの更新が定期的であり、プロシージャを実行する手動タスクから自分を救おうとしている場合は、eventsを使用してストアド プロシージャを実行することもできます。

別のオプションは、トリガーで更新される非正規化/集計テーブルを使用することです。ソース テーブルのデータを更新すると、トリガーによって集計テーブルが自動的に最新の状態に維持されます。

ストアド プロシージャ、ビュー、トリガー、およびイベントのドキュメントへのリンクを次に示します。

于 2010-07-12T18:38:32.030 に答える