Conversei com um professor universitário que ensinava PL/SQL depois que fiz uma apresentação em uma conferência. Minha palestra foi sobre boas práticas de PL/SQL; um dos meus slides dizia simplesmente "Não use gatilhos". O professor me disse que acha difícil conciliar esse conselho com as necessidades do currículo. Eles têm que ensinar a seus alunos toda a sintaxe, mas ele admitiu que muitas vezes eles definem tarefas que exigiam soluções que não usaríamos ao escrever software profissionalmente.
Esta é uma pergunta e tanto. A abordagem correta é usar uma restrição de verificação, como a resposta de Gordon mostra . As restrições são mais eficientes e idiomáticas também. Mas seu professor quer que você escreva um gatilho, então aqui está seu código, corrigido.
CREATE OR REPLACE TRIGGER CheckAdvance
BEFORE INSERT OR UPDATE OF advance ON titles
FOR EACH ROW
BEGIN
IF (:new.advance < 0
OR :new.advance > 100)
THEN
raise_application_error(-20000
, 'Advance cannot be less than zero or greater than one hundred.');
END IF;
END;
Pontos a observar:
- CREATE OR REPLACE significa que podemos alterar o código do gatilho sem uma instrução DROP preliminar.
- BEGIN e END blocos de quadro de código, como corpos de gatilho.
- Condicionais estáticos são enquadrados com palavras-chave IF ... END IF; WHEN é para sair de construções de loop.
- Valores de coluna da tabela de referência com palavras-chave :NEW (e :OLD) - observe os dois pontos.
- Use RAISE_APPLICATION_ERROR para lançar uma exceção; o número do erro deve estar no intervalo -20999 a -20000 que a Oracle reserva para exceções definidas pelo usuário.
- Torne sua mensagem de erro significativa:diga a seus usuários o que eles fizeram de errado em vez de fazê-los adivinhar.
- Aprenda a usar o recuo para tornar seu código legível. Seus futuros colegas de trabalho agradecerão por isso.
