Die meisten Datenbankverwaltungssysteme beschränken Prüfbeschränkungen auf eine einzelne Zeile, mit Zugriff auf Konstanten und deterministische Funktionen, aber nicht auf Daten in anderen Tabellen oder auf Daten, die aufgrund der Transaktionsisolation für die aktuelle Transaktion unsichtbar sind.
Solche Beschränkungen sind keine echten Tabellenprüfbeschränkungen, sondern eher Zeilenprüfbeschränkungen. Da diese Beschränkungen im Allgemeinen nur überprüft werden, wenn eine Zeile direkt aktualisiert wird (aus Leistungsgründen), und oft als implizite INSERT oder UPDATE Trigger implementiert sind, könnten Integritätsbeschränkungen durch indirekte Aktionen verletzt werden, wenn es diese Einschränkungen nicht gäbe. Darüber hinaus würden ansonsten gültige Änderungen an diesen Datensätzen durch die CHECK-Beschränkung verhindert werden. Einige Beispiele für gefährliche Beschränkungen sind:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
Benutzerdefinierte Auslöser können verwendet werden, um diese Einschränkungen zu umgehen. Obwohl die Implementierung ähnlich ist, ist es semantisch klar, dass Trigger nur ausgelöst werden, wenn die Tabelle direkt geändert wird, und dass es in der Verantwortung des Designers liegt, indirekte, wichtige Änderungen in anderen Tabellen zu behandeln; Constraints hingegen sollen „immer wahr“ sein, unabhängig von den Aktionen des Benutzers oder der mangelnden Voraussicht des Designers.