A maioria dos sistemas de gerenciamento de banco de dados restringe as restrições de verificação a uma única linha, com acesso a funções constantes e determinísticas, mas não a dados em outras tabelas, ou a dados invisíveis à transação atual devido ao isolamento da transação.
As restrições não são verdadeiramente restrições de verificação de tabela, mas sim restrições de verificação de linha. Como essas restrições geralmente só são verificadas quando uma linha é atualizada diretamente (por razões de desempenho) e muitas vezes implementadas como implícitas INSERT ou UPDATE gatilhos, as restrições de integridade poderiam ser violadas por ações indiretas se não fosse por essas limitações. Além disso, outras modificações válidas para esses registros seriam então impedidas pela restrição CHECK. Alguns exemplos de restrições perigosas incluem:
CHECK ((select count(*) from invoices where invoices.customerId = customerId) < 1000)CHECK (dateInserted = CURRENT_DATE)CHECK (countItems = RAND())
triggers definidos pelo usuário podem ser usados para contornar essas restrições. Embora semelhante na implementação, é semanticamente claro que os triggers só serão disparados quando a tabela for diretamente modificada, e que é responsabilidade do projetista lidar com mudanças indiretas e importantes em outras tabelas; as restrições, por outro lado, destinam-se a ser “verdadeiras em todos os momentos”, independentemente das ações do usuário ou da falta de previsão do projetista.