MySQLトリガーまたはトランザクションを使用していますか？

MySQLトリガーまたはWebサイトでのトランザクションの使用について、ご意見をお聞かせください。

実際、私はpayment-で履歴テーブルを持っていますUserId | OperationId | Comment | Credits | Sign (debit or credit)。したがって、各支払い操作がこのテーブルに挿入されます。

ただし、ユーザーがアクションを実行するたびに、ユーザーの合計クレジット額を計算するのに時間がかかります。そのため、各ユーザーの合計クレジット額をユーザーprofileテーブルに保持することをお勧めします。

ここに問題があります。profileテーブルの合計クレジット額がpayment履歴テーブルの操作と常に同期していることを確認するにはどうすればよいですか？

私は2つの方法を使用すると思いました：

• MySQLトリガーまたは
• ソースコードでコーディングされたトランザクション

どちらがより信頼できますか？大規模なデータベース（100.000ユーザー以上）がある場合はどうなりますか？

これを行うための提案はありますか？

BD MySQLエンジンはInnoDBです。

間違いなく、私はトリガーを除外し、厳密にトランザクションを維持します。

トリガーは、本来、ストアドプロシージャです。彼らの行動をロールバックするのは事実上難しい。基礎となるすべてのテーブルがInnoDBである場合でも、比例した量の共有行ロックが発生し、排他的行ロックによる煩わしい断続性が発生します。トリガーがINSERTとUPDATEを含むテーブルを操作して、トリガーへの各呼び出し内で強力なMVCCを実行するために停滞している場合は、このような状況になります。

これを、適切なデータ検証プロトコルがMySQLのストアドプロシージャ言語で実装されていないという事実と組み合わせてください。ストアドプロシージャ言語がトランザクション環境を処理できる場合、ビジネスインテリジェンスはデータベースに含まれていても問題ありません。MySQL DBAとして、私は正直に言って、MySQLにはそうではないことを言わなければなりません。Oracle（PL / SQL）、PostgreSQL（PL / pgSQL）、およびSQL Server（T-SQL）は、MySQLよりも優れています。

トランザクションに関しては、MySQLはその主要なACID準拠のストレージエンジン（MySQL 5.5のDeafultストレージエンジン）としてInnoDBを持っています。優れたクラッシュ回復機能があり、ACIDコンプライアンスプロトコルに従います。

私は毎回トリガーよりもトランスアクチオンを選びます。

Rolandoの評価に同意します。ビジネスロジックはアプリケーションに常駐し、トランザクションでデータベースを変更する必要があります。

もちろん、10万人のユーザーへのスケーリングは、アプリケーションとそれが生成するデータベーストラフィックに依存します。MySQLでトランザクションの書き込み負荷が高い場合、許容できるアプリケーション応答を維持するために、データセットのシャーディングや複製の負担にすぐに直面する可能性があります。

ただし、MySQLのシャーディングに代わるものがあります。その1つがClustrix（私の雇用主）です。これは、並列スケーラブルな高性能シングルインスタンスSQLデータベースシステムです。クラスター化されたデータベースシステムであり、単一のMySQLサーバーとして表示されます。このスレッドで説明されているデータベースをシームレスにClustrixの単一インスタンスで100,000人のユーザーにスケーリングする場合、シャーディングや追加のアプリケーションロジックは必要ありません。

ローランドからの良い答え。

さらに、トリガーはロジックに使用しないでください。相互に関連するいくつかのトリガーは後で混乱するためです。ストアドプロシージャまたはクライアントサイドプロシージャの一連の優れた命令は、データベース内の一連の隠されたロジックよりも明確にビジネスロジックを通過できます。また、トリガー元のテーブルに関してトリガーにも制限があります。そのため、ロジックを2つの異なる場所に分割することがあります。

さらに、これらの計算がビジネスロジックサーバーでどの時点で発生するかを最適化する方法が見つかるかもしれませんが、トリガーは毎回トリガーされます。トリガーをオフにし、テーブルを更新してから、トリガーを再度有効にします。これは、トリガーロジックをそのコードに含める必要があることも意味します。

さらに、コードのビジネスロジック部分にすべてのロジックを含める必要はありません。ストアドプロシージャを使用して、テーブルの整合性を強化することもできます。これにより、トランザクションが開始され、複数の更新が行われ、何かが失敗した場合に適切にロールバックすることができます。このようにして、たとえば、データベースを見ている人は、注文を挿入するためのロジックを見ることができます。これは今日の世界ではそれほど重要ではありません。Webサービスがdbへの単一のアクセスインターフェイスになる可能性があるためです。しかし、複数の実行可能ファイルがDBにアクセスできる場合、これは巨大になる可能性があります。

さらに、とにかくトランザクションを行うつもりです-トリガーなしでトリガーを実行するつもりはありません... したがって、トランザクションの開始方法を知っておくとよいでしょう。いくつかのことを行います。トランザクションを終了します。コードにこのパターンが見られる場合、それを使用するもう1つのコードは、認知負荷が軽くなります。トリガーがあることを覚えている場合は、トリガーによって影響を受けるトランザクションについて、特に他のテーブルもプルされている場合はトリガーを持っている可能性がある場合に、別の考えを強いられます。

基本的に、定期的にスケジュールされたcronジョブ（またはデータベースエージェントジョブ）と適切なストアドプロシージャの間で、必要なものの99％を達成できます。1％; プロジェクトを再考します。