Większość systemów zarządzania bazą danych ogranicza ograniczenia sprawdzające do pojedynczego wiersza, z dostępem do stałych i funkcji deterministycznych, ale nie do danych w innych tabelach lub do danych niewidocznych dla bieżącej transakcji z powodu izolacji transakcji.
Takie ograniczenia nie są naprawdę ograniczeniami sprawdzającymi tabelę, ale raczej ograniczeniami sprawdzającymi wiersz. Ponieważ te ograniczenia są generalnie weryfikowane tylko wtedy, gdy wiersz jest bezpośrednio aktualizowany (z powodów wydajnościowych) i często implementowane jako implikowane INSERT lub UPDATE wyzwalacze, ograniczenia integralności mogłyby zostać naruszone przez pośrednie działanie, gdyby nie te ograniczenia. Co więcej, w przeciwnym razie prawidłowe modyfikacje tych rekordów byłyby uniemożliwione przez ograniczenie CHECK. Niektóre przykłady niebezpiecznych ograniczeń obejmują:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
Do obejścia tych ograniczeń można użyć wyzwalaczy zdefiniowanych przez użytkownika. Chociaż podobne w implementacji, jest semantycznie jasne, że wyzwalacze będą uruchamiane tylko wtedy, gdy tabela jest bezpośrednio modyfikowana, a odpowiedzialnością projektanta jest obsługa pośrednich, ważnych zmian w innych tabelach; ograniczenia z drugiej strony mają być „prawdziwe przez cały czas”, niezależnie od działań użytkownika lub braku przewidywania projektanta.
.