12

パフォーマンスのためにトランザクション データベース内のデータを非正規化する場合、(少なくとも) 3 つの異なるアプローチがあります。

  1. 正規化されたトランザクション データと非正規化されたレポート/分析データの両方を更新するストアド プロシージャを介して更新をプッシュします。

  2. セカンダリ テーブルを更新するトランザクション テーブルにトリガーを実装します。これは、ほとんどの場合、履歴を維持するときに取られるルートです。

  3. 処理を夜間のバッチ プロセスに延期し、データ マート/ウェアハウスに ETL を実行する可能性があります。

この質問の目的のために、オプション 3 は実行できないと仮定しましょう。これは、ドメインでは非正規化されたデータが正規化されたデータと常に一致している必要があるためです。私が頻繁に扱う階層集計は、その一例です。

私は最初の 2 つのアプローチの両方をかなり使用してきましたが、最近はトリガーベースのアプローチに傾倒していますが、まだ発見していない「落とし穴」があるかどうか疑問に思っています。この質問をする価値があるので、将来長期的な決定を下すときに心に留めておくべきいくつかのアイデアがあります.

あなたの経験では、リアルタイムの非正規化データを維持するという特定の目的のために、どちらのツールの長所と短所は何ですか? どのような状況でどちらか一方を選択しますか?その理由は?

（PS「トリガーが複雑すぎる」や「すべての更新は常にストアドプロシージャを通過する必要があります」などの回答はしないでください-質問のコンテキストに適したものにしてください。）

4

3 に答える 3

11

トリガーは自動の副作用であり、トリガーの副作用のために何かをしたいができない場合は、ほぼ確実にあなたを噛み砕きます。主に、システムを他の外部システムとのXAトランザクションに参加させるなどのことです。トリガーはこれを不可能にします。また、トリガーアクティベーターを再度実行することによってのみアクティブ化できるのは副作用ロジックです。ウェアハウスでデータを再作成する場合は、いくつかのプロシージャを実行して再作成することはできません。トリガーを起動するすべてのアクティビティを実行する必要があります。これは悪夢です。INSERTS、UPDATES、およびDELETESは、べき等で直交している必要があります。トリガーは、ワークフローを単純化していると思っていても、ワークフローを不必要に複雑にします。

于 2010-01-18T20:31:52.023 に答える
10

トリガーは、テーブルのパスを複数更新する場合に便利です。

ストアド プロシージャを使用し、少なくとも約 4 つのパスがあります (追加、更新、非アクティブ化、コピー)。

実行するアクションや影響する行数に関係なく、トリガーで挿入/更新したばかりのデータを操作する方が簡単です。

ストアド プロシージャは、単一の更新パスに対してのみ機能します。コードを繰り返したくない場合は...

現在、トリガーの TRY/CATCH は、正確で予測可能なエラー処理を意味します。SQL Server 2000 以前のトリガーは、(控えめに言っても) 理想的ではないエラー/ロールバックでバッチの中止を引き起こしました。とにかく、トリガーはより信頼できるものになりました。

于 2010-01-18T20:26:56.433 に答える
0

ビジネス要件とデータベースの使用方法によって異なります。たとえば、テーブルに影響を与える多くのアプリケーションと多くのインポートがあるとします (テーブルに影響を与える可能性のあるものが何百もあります)。また、すべての価格を 10% 更新するなどのことを行うために、SSMS から実行されるクエリを作成する必要がある場合もあるとします (prod でもそうです)。これらのタイプのことを行う場合、ストアド プロシージャは実用的ではありません。データベースに影響を与える可能性のあるすべての方法がカバーされることはありません。

このデータ変更がデータ整合性のために必要な場合、または多くのアプリケーションやプロセス (インポート、SQL Server ジョブなど) がデータに影響を与える可能性がある場合、それはトリガーに属します。

データの変更がたまにしか必要ない場合、または 1 つのアプリケーションのみからデータの変更方法を完全に制御できる場合は、ストアド プロシージャで問題ありません。

于 2013-09-09T20:18:39.883 に答える