La mayoría de los sistemas de gestión de bases de datos restringen las restricciones de comprobación a una sola fila, con acceso a las constantes y a las funciones deterministas, pero no a los datos de otras tablas, o a los datos invisibles para la transacción actual debido al aislamiento de la transacción.
Estas restricciones no son realmente restricciones de comprobación de tablas, sino más bien restricciones de comprobación de filas. Debido a que estas restricciones generalmente sólo se verifican cuando una fila se actualiza directamente (por razones de rendimiento) y a menudo se implementan como disparadores implícitos INSERT o UPDATE, las restricciones de integridad podrían ser violadas por una acción indirecta si no fuera por estas limitaciones. Además, la restricción CHECK impediría la realización de modificaciones válidas en estos registros. Algunos ejemplos de restricciones peligrosas son:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
Se pueden utilizar disparadores definidos por el usuario para evitar estas restricciones. Aunque son similares en su implementación, está semánticamente claro que los triggers sólo se dispararán cuando la tabla se modifique directamente, y que es responsabilidad del diseñador manejar los cambios indirectos e importantes en otras tablas; las restricciones, por otro lado, están pensadas para ser «verdaderas en todo momento», independientemente de las acciones del usuario o de la falta de previsión del diseñador.