mcureenab mir mcureenabЕсли данные изменены в обход СУБД и её механизмов защитыЭто как? Остановить сервис СУБД, открыть файл БД каким-то редактором?1. Отключение механизмов защиты пользователем.
2. Сбой носителя.
3. Сбой экземпляра СУБД.
4. Холодное восстановление резервной копии.
5. Изменение файла БД посторонним редактором.
6. И прочая. ....

1. Пользователь может просто взять и отключить защиту? Это мне напомнило плохие голливудские фильмы про хакеров, где при первом отлупе от ломаемой системы "хакер" просто-напросто вводит команду "обойти защиту" -- и готово.
2, 3 -- при чем здесь ввод данных в обход СУБД?
4. Восстановление бэкапа -- штатная операция -- никак не ввод данных в обход СУБД.
5. Вот про то ж я и говорил, но при работающей СУБД это невозможно (если СУБД нормальная).
6. А что прочая?
mcureenabТак что возможностей извлечь из БД кривые данные ничуть не меньше, чем получить их от пользователя.Речь вроде шла об "изменении данных в обход СУБД и её механизмов защиты". При чем здесь извлечение? Простейший способ извлечь из БД кривые данные -- ошибочный запрос. Никакого "изменения файла БД посторонним редактором" тут и не нужно.
mcureenabС точки зрения программы БД такой же внешний источник данных, как любой файл или устройство ввода.Это так, видимо, для создаваемых вами систем, где вы "не переусложняете базу ограничениями целостности". Уж простите. Для моих "переусложненных" баз извлекаемая из них информация уж существенно подостовернее будет, чем "любой файл или устройство ввода".

Я утерял нить разговора. Если мы говорим о зоне ответственности СУБД, то повреждения носителей и т.п. здесь не вообще при чем. За физическую работоспособность СУБД отвечает аппаратура и персонал. При современных технологиях аппаратного резервирования и резервного копирования вероятность искажения данных по техническим причинам пренебрежимо мала по сравнению с другими причинами. Единственная вообще заслуживающая внимания причина нахождения в БД недостоверных данных очень проста -- эти данные в БД такими поступили. И нет никакой дилеммы, где должна происходить проверка целостности: в СУБД или в клиентском приложении. Она должна происходить и в СУБД, и в клиентском приложении. Но в СУБД -- обязательно, т.к. приложение обойти можно, а СУБД -- нельзя.

Ну, а фраза "возможностей извлечь из БД кривые данные ничуть не меньше, чем получить их от пользователя" звучит для меня смехотворно. Много лет мы делаем импорт в БД данных, набитых когда-то пользователями в Excel. Уж я то насмотрелся, как пользователи вводят данные, когда их ничто жестко не контролирует. Пропуски там, где их быть не должно. Записи на одну и ту же дату, хотя такого быть не должно. Текстовые комментарии там, где должны быть числа. Об опечатках вообще можно не упоминать. СУБД, в которой заданы хотя бы основные ОЦ, такого принципиально не пропускает. Все это чистится, чиниться и тогда укладывается в базу. Поэтому не надо этих сказок, умоляю.

(К слову, при порче БД СУБД вовсе не будет, ничего не подозревая, извлекать из БД неверные данные. С вероятностью 99.9% СУБД просто откажется работать с такой БД или ее поврежденной частью. Так же и маловероятно предположение о возможности при работающей СУБД внешней программой менять или даже читать из БД данные. Скажем, сервис MS SQL Server налагает эксклюзивный доступ к файлам БД, и ни одна программа не может этот файл даже читать)