Самое простое - алгоритм проверки вынести в SP.
Для особого извращения можно организовать
вызов этой процедуры из триггера на insert и
update /что не очень грамотно :)/

По поводу неграмотности использования тригера

Дело в том, что тригер запускается ВСЕГДА.
Поэтому возникают серьезные проблемы,
например,

1. При списочном изменении
каскад изменений может в целом быть
корректен, но блокироваться тригером
на каждом шаге
2. При администрировании

И т.д. и т.п.

В целом - тригер проверяет не СОСТОЯНИЕ данных,
а операции с ними...

Более грамотно писать специальные интерфейсы работы
с объектами (куды и засовывается бизнес-логика),
и избавляться от прямой работы с данными :)

2dao

Для описания недопустимости значений
у нас был разработан даже свой псевдоязык
Типа для четных а) не может быть б) кратных 7...

Мы даже "ранжировали" ограничения, например,
по типу операции и правам доступа
/при заведении счета допускались некоторые
изменения, ктр блокируюися в дальнейшем,
некоторые изменения разрешены только при
подтверждении или согласовании с шефом и т.п./
Пример могу привести :)

2Nickolay
Коля - прочти мое сообщение внимательно :)
Мы не добавляем вызов каждой SP в каждое приложение.
Это, действительно, неразумно...
Дело в том, что никакое приложение не содержит
напрямую insert, update или delete - все эти операции
осуществляются через интерфейсы /SP-в простейшем
случае/... Соответственно, все проверки и пр.
НЕ ТРЕБУЮТ НИКАКИХ ИЗМЕНЕИЙ НИКАКИХ ПРИЛОЖЕНИЙ
/если приложения с самого начала писались грамотно :)/

2Nickolay

Конечно, можно сносить... :)
Жалко, что это делается постоянно :)
И не решить даже уровнем доступа...
Поэтому, часто целесообразнее просто не использовать
/хотя, конечно, иногда тригера очень полезны,
но не для задачи, вынесенной в топик/