Alexander A. SakКак это делаю я.
БД для приемной комиссии. Развивается мной уже скоро как 10 лет. То, что одними ограничениями целостности не обойтись я понял где-то на 4-5 год, когда с Клариона, потом Парадокса перешел на Интербейз. Связано с особенностями работы. Например, я не могу сделать обязательным поля, которые должны быть обязательными. Потому что в основном они должны быть введены обязательно к концу работы приемной комиссии, когда надо получать статистику. Тем более есть периоды, когда операторы должны быстро принимать документы, и в то же время должны что-то внести в запись о личном деле. И чем меньше обязательных полей на этом этапе, тем лучше. Потом они заполнят все, что надо, но когда на пороге кабинета двадцатиметровая очередь абитуриентов, надо сделать минимум ввода. Причем это в летний (официальный) период работы. Во время проведения весенних испытаний вообще не надо регистрировать процентов 70% информации.
В итоге у меня родился блок проверки наличия ошибок. Например, каждый абитуриент должен указать как минимум один факультет. То есть для каждой записи в мастере должен быть как минимум одна запись в детайле. Как в IB/FB описать такой констрейнт? Тем более, что в часы пик личное дело жедательно сохранить как можно быстрее (надо получить номер абитуриента и поставить его на личном деле, пропуске и экзаменационном листе). С процедурой проверки ошибок такие записи определяются на раз. Второй пример - ЕГЭ. Абитуриент говорит, что математику и историю он будет засчитывать ЕГЭшную. Но номера свидетельства ЕГЭ еще нет, потому что экзамены он будет сдавать через месяц. О том, что экзамены будут ЕГЭшные мы пометим, но о том, что номера свидетельства до сих пор нет, кто-то должен напоминать. Третье - поля типа "Год окончания учебного заведения", "Тип учебного заведения", "Стаж работы по специальности" и пр. нужны после зачисления, когда готовятся министерские отчеты. Во время запарок совсем не до них. Но когда-то кто-то должен вывести список личных дел, в которые надо в конце концов заполнить все.
Подобным и занимается блок проверки наличия ошибок. Сейчас посмотрел. Проверяется около 40 различных ситуаций. Для пользователей выглядит все очень просто: администратор периодически запускает процедуру поиска ошибок. Она занимает около 2 минут, поэтому запускается вручную. Обновляется список ошибок. Список из двух колонок: название ошибки и количество личных дел с этой ошибкой. Enter на строке с ошибкой раскрывает список косячных личных дел. Ищи личное дело и исправляй. В комментариях для некоторых отчетных форм написаны причины, по которым могут не сходиться цифры. Там делаются ссылки на блок проверки ошибок. Типа "не должно быть ошибки ХХХ, иначе сумма по колонке NNN будет меньше значения в ячейке MMM".

Извинте за многословие. Это все пиво. Если одним предложением, то все просто: проверки постфактум.
Не легче ли было бы разбить информацию на категории, где информация каждой категории может иметь статусы "Не ведена", "Не полностью ведена", "Полностью ведена" (ну и возможны другие варианты). Соответствующие триггеры по бизнес-правилам при добавлении и изменении информации вычисляют, к какому состоянию можно отнести текущую информацию и присваивают соотвествующей значение в поле "Статус". Таким образом получаются не нужным никакие блоки поиска и проверок ошибок, примитивным запросом всегда можно получить, что как и где еще не заполнено или не правильно заполнено. Плюс БД не зависит от внешних приложений - любая сессия, без разницы откуда вызванная, при наличии достаточных прав доступа, может наряду с операторами импортировать , добавлять и изменять данные в БД, не задумываясь насколько они полностью достоверны и полностью заполнены - опять же все будет контролировать БД.

Я лично не вижу препятствий в реализации данной схемы на IB/FB - BEFORE триггера там есть, устанавливать значения полей во время вставки и правки записей в них можно, ХП вроде тоже как поддерживаются, так что смело можно на ХП реализовать блок вычисления статуса информации на основании представленных данных и вызывать из соотвествующих триггеров, занося результат в специально выделенное поле.

Alexander A. Sak ASCRUSЯ лично не вижу препятствий в реализации данной схемы на IB/FB - BEFORE триггера там есть, устанавливать значения полей во время вставки и правки записей в них можно, ХП вроде тоже как поддерживаются, так что смело можно на ХП реализовать блок вычисления статуса информации на основании представленных данных и вызывать из соотвествующих триггеров, занося результат в специально выделенное поле.
Ну примерно так и есть. Все вычисляется в ХП. Только вызывается не триггером и ни в какое поле не заносится. Зачем? Кстати, эта ХП и получается блоком определения ошибок.
Легче один раз вычислить и запомнить, чем это делать каждый раз. Когда в БД помимо самой информации хранится флаг ее состояния (актуальности), очень легко писать запросы/отчеты/обработку на другие действия - например, в Вашем случае вывести график состояния заполнения информации, отчет о данных, подлежащих дальнейшему заполнению, реализовать на триггерах бизнес-логику контроля заполнения другой информации - например, запрещать, если статус информации не выставлен в полную готовность и т.д.

В Вашем случае получается, что информация, хранимая в БД - это просто информация, которая ничего не может сказать о том, насколько она актуальна, и кто то должен вызвать чего то (в данном случае ХП), чтобы определить ее состояние. В моем варианте информация уже сама несет в себе знание о своем состоянии и соотвествующе уже готова к полноценному использованию как внутри БД, так и с клиентских/отчетных приложений.