В антипаттерне, описанном в данной главе, используются написанные разработчиком скрипты для вывода отчетов о поврежденных данных.
Например, в нашей базе данных ошибок столбец Bugs.status ссылается на таблицу поиска BugStatus. Чтобы найти ошибки с недопустимым значением статуса, можно было бы воспользоваться запросом, подобным следующему:
Файл npvinepa:_Keyless-Entry/anti/find-orphans.sql
SELECT b.bug_id, b.status
FROM Bugs b LEFT OUTER JOIN BugStatus s ON (b.status = s.status)
WHERE s.status IS NULL;
Представьте себе, что вам требуется написать аналогичный запрос для каждого ссылочного отношения в базе данных.
Если у вас есть привычка проверять нарушенные ссылки, возникает вопрос, как часто надо выполнять эти проверки? Выполнение сотен проверок каждый день или даже чаще превращается в раздражающую рутину.
Что происходит, когда обнаруживается нарушенная ссылка? Можно ли ее исправить? Иногда такая возможность есть. Например, можно было бы изменить значение статуса недопустимой ошибки на целесообразное стандартное значение.
Файл npMMepa:_Keyless-Entry/anti/set-default.sql
UPDATE Bugs SET status = DEFAULT WHERE status = 'BANANA';
Есть и другие случаи, когда невозможно синтезировать данные для исправления таких типов ошибок. Например, столбец Bugs. reported_by должен ссылаться на учетную запись пользователя, сообщившего о заданной ошибке, но если это значение недопустимо, какую пользовательскую учетную запись следует выбрать в качестве замены?
Главная
Каталог файлов
