見るとわかるのですけど、大雑把に書くと次のような感じになります。このトリガを関連付けたいテーブル名を指定します。対して発行されると、このトリガが自動的に実行されます。実行したいプログラムを記述します。いう2つの特別なテーブルを参照することができます。これらを利用することで、更新前および更新後のデータ状態を把握することが可能になります。これらの意味は発行したクエリによって次のような感じになります。更新されたレコードとみなす条件を指定します。更新されたときにのみ処理を行う、と言うような指定が可能になります。場合、一度のクエリ発行に対して1度だけ実行されることになるそうです。テーブルに複数のレコードが存在するものとしてコーディングする必要があります。役に立つたたないは別として、とりあえず思い当たる例を挙げてみようと思います。雰囲気だけとらえて、いろいろと応用してやってくださいませ。ここでは次ぎのような2つのテーブルを用意したとして、これらに関連したトリガを用意してみる、と言う感じで話を進めます。登録制で運用していたとして、書き込みとは別に、各ユーザの最終書き込み日時および通算書き込み回数を別テーブルに一括して管理するような場合を考えて見ます。方の基本情報も更新するとします。手段はあると思いますけど、これをトリガでやってみると...。対して書き込みを行ったとき。処理を行うことにします。既存の書き込みに対する更新には反応しないものとします。増加させる、、、そんな感じで作ってみると、次のような感じのトリガになると思います。内容も更新されるようになります。新しい日付に置き換わるようなトリガを用意してみます。クエリが処理される場合。どちらかが変更された場合を、編集されたとみなすならば、次のようなトリガになると思います。記録されることになります。書き込みを制限するたとえば何らかの理由で書き込みを禁止させたいとします。あった場合には、その処理を無効にする、と言う方法で対処することが可能です。言う感じで利用するようです。3番目の引数の意味が良くわからないですが...。トリガをひとつ定義していますが、このようなトリガを両方利用するような場合は、分ける必要性がない限りはひとつのトリガに両方の処理を詰め込んでしまった方が安全そうな気がします。システムテーブルを参照します。設定されているので、検索条件としてこれを指定します。することでトリガの一覧だけが取り出せます。ストアドプロシージャを呼び出します。宣言した際のソースコードを参照することができます。暗号化されていない場合に限ります。削除することができます。多く容量がもらえます。多く容量がもらえます。