Majoritatea sistemelor de gestiune a bazelor de date restricționează constrângerile de verificare la un singur rând, cu acces la constante și funcții deterministe, dar nu și la datele din alte tabele sau la datele invizibile pentru tranzacția curentă din cauza izolării tranzacției.
Aceste constrângeri nu sunt cu adevărat constrângeri de verificare a tabelelor, ci mai degrabă constrângeri de verificare a rândurilor. Deoarece aceste constrângeri sunt, în general, verificate numai atunci când un rând este actualizat direct (din motive de performanță,) și sunt adesea implementate ca declanșatori impliciți INSERT sau UPDATE, constrângerile de integritate ar putea fi încălcate prin acțiuni indirecte dacă nu ar fi vorba de aceste limitări. În plus, modificările altfel valabile ale acestor înregistrări ar fi atunci împiedicate de constrângerea CHECK. Câteva exemple de constrângeri periculoase includ:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
Pentru a ocoli aceste restricții se pot utiliza declanșatoare definite de utilizator. Deși sunt similare în implementare, este clar din punct de vedere semantic că declanșatoarele vor fi declanșate doar atunci când tabelul este modificat direct și că este responsabilitatea proiectantului să se ocupe de modificările indirecte, importante din alte tabele; constrângerile, pe de altă parte, sunt menite să fie „adevărate în orice moment”, indiferent de acțiunile utilizatorului sau de lipsa de previziune a proiectantului.
.