A legtöbb adatbázis-kezelő rendszer az ellenőrző megkötéseket egyetlen sorra korlátozza, a konstansokhoz és determinisztikus függvényekhez való hozzáféréssel, de más táblák adataihoz vagy az aktuális tranzakció számára a tranzakció elkülönítése miatt láthatatlan adatokhoz nem.
Az ilyen megkötések nem igazán táblaellenőrző megkötések, hanem inkább sorellenőrző megkötések. Mivel ezek a korlátozások általában csak akkor kerülnek ellenőrzésre, amikor egy sort közvetlenül frissítenek (a teljesítmény miatt), és gyakran implikált INSERT vagy UPDATE triggerekként vannak implementálva, az integritási korlátozások közvetett művelettel is megsérthetők lennének, ha nem lennének ezek a korlátozások. Ráadásul ezeknek a rekordoknak az egyébként érvényes módosításait a CHECK korlátozás megakadályozná. Néhány példa a veszélyes korlátozásokra:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
A felhasználó által definiált triggerek segítségével megkerülhetők ezek a korlátozások. Bár a megvalósítás hasonló, szemantikailag egyértelmű, hogy a triggerek csak akkor lépnek működésbe, ha a táblát közvetlenül módosítják, és a tervező felelőssége, hogy kezelje a közvetett, fontos változásokat más táblákban; a korlátozásoknak ezzel szemben az a céljuk, hogy “mindig igazak” legyenek, függetlenül a felhasználó műveleteitől vagy a tervező előrelátásának hiányától.