Eu tenho uma tabela onde todas as ações afetam linhas únicas (inserir e atualizar, sem deletar, mas se houvesse, elas também seriam individuais). Estou pensando em usar um UDF em uma restrição de verificação para garantir que um valor de campo seja usado apenas em combinação com outro valor (dois FK's, na primeira vez que A=1 é usado, B=x torna-se fixo, de modo que se x = 4 então A=1 nunca pode ser combinado com B=3 ou qualquer coisa exceto 4).
Quais são as desvantagens de fazer isso, além do tempo adicional inelegível gasto ao inserir/atualizar a linha?
ATUALIZAÇÃO: o aplicativo não fornece um mecanismo para alterar a coluna A ou B após a criação da linha.
Você pode armazenar as colunas A e B em uma tabela separada. Certifique-se de que sua tabela tenha uma chave primária em A e uma restrição exclusiva em (A,B) Consulte (A,B) em sua tabela. A chave primária em A garantirá apenas um B por A. A chave estrangeira sem ON UPDATE CASCADE garantirá que B não mude, desde que a linha seja referenciada na tabela filha.
UDFs que acessam outras tabelas geralmente devem ser evitadas em restrições CHECK (*).
Quase não há caso de uso em que eles se comportem inteiramente como esperado pelo usuário, quase certamente não há um único mecanismo SQL que os implemente corretamente de acordo com a semântica prescrita pelo padrão para restrições CHECK, breve, se você fizer isso, 'É quase certo que será o próximo na fila a postar mais uma pergunta "CHECK constraint not working" em algum fórum em algum lugar.
Você disse que "os gatilhos parecem mais pesados". Você tem razão. O problema é que você espera que seu mecanismo seja capaz de inferir todo esse "serviço pesado" de sua declaração de restrição "simples". Essa expectativa é injustificada.
(*) Como sempre, a exceção são as pessoas que "sabem o que estão fazendo". Mas se você estivesse entre eles, não precisaria perguntar nada em primeiro lugar.