あなたの問題を正確に理解していないので、私の答えが実際に何かを解決するのか、根本的な問題を悪化させるだけなのか、完全にはわかりません. 特に、パフォーマンスや並行性の問題に直面している場合、これは機能しない可能性があります。
元のテーブルを更新できる場合は、次のように datetime2 フィールドを追加するだけです
InsertDate datetime2 NOT NULL DEFAULT GETDATE()
できれば、テーブルにインデックスを作成してから、適切な間隔で、InsertDate > GetDate - X を持つ行の数を確認してテーブルをポーリングします。
この特定のケースでは、ポーリング プロセスを非コミットで読み取る (または を使用するWITH NOLOCK
) ことでメリットが得られる場合がありますが、そうする場合は注意が必要です。
テーブル自体を変更できず、別のプロセスまたはジョブに関連する変数を監視させることができない、または行わない場合は、次のことをお勧めします。
- Datetime2 列を 1 つだけ持つ「カウンター」テーブルを作成します。
元のテーブルで、次のような AFTER INSERT トリガーを作成します。
- datetime-field が X 秒より古いすべての行を削除します。
- 現在の時刻を含む 1 行を挿入します。
- カウンタ テーブルに存在する行が多すぎるかどうかをカウントします。
- 必要に応じて行動します-つまり。送信者に通知する/例外をスローする/メールを送信するなどの手順を実行することにより。
元のテーブルを変更できる場合は、代わりにそのテーブルに datetime 列を追加し、トリガーが X 秒経過していないすべての行をカウントするようにし、必要に応じて動作します。
また、すべてのハウスキーピングを行う別のプロセス (つまり、SQL ジョブまたは自家製サービスなど) を取得することも検討します。古い行を削除し、行を数え、それに基づいて行動します。これをトリガーの働きとして維持するのは良い設計ではなく、おそらく長期的には問題を引き起こすでしょう。
可能であれば、他のプロセスでハウスキーピングを行うことを検討する必要があります。
更新: より良い解決策は、おそらくトリガーが通知 (つまり、日時) をキューに挿入することです。そのキューに対して何かをリッスンしている場合は、ロジックを記述して、しきい値を超えたかどうかを判断できます。ただし、そのためには、ロジックの一部を別のプロセスに移動する必要があります。最初は、これはオプションではないと理解していました。