ほとんどのデータベース管理システムでは、チェック制約を 1 つの行に制限し、定数や決定性関数にはアクセスできますが、他のテーブルのデータ、またはトランザクション分離により現在のトランザクションからは見えないデータにはアクセスできないようにしています。 これらの制約は一般的に行が直接更新されたときにのみ検証され、しばしば暗示的な INSERT または UPDATE トリガとして実装されますので、これらの制限がなければ、整合性制約は間接的な動作によって違反される可能性があります。 さらに、これらのレコードに対する他の有効な変更は、CHECK制約によって阻止されるでしょう。 危険な制約の例をいくつか挙げます。
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
ユーザー定義のトリガーはこれらの制限の回避に使用可能です。 実装は似ていますが、トリガはテーブルが直接変更された時のみ起動され、他のテーブルの間接的で重要な変更を処理するのは設計者の責任であることは意味的に明らかです。一方、制約はユーザーの行動や設計者の先見性のなさとは無関係に「常に真」であることを意図しています。