Извлечение данных из базы данных с нарушенной целостностью

Question

Должно ли приложение ожидать неожиданного при получении данных из базы данных? Допустим, мы сохранили значение перечисления в столбце (int или text). Когда мы возвращаем значения из базы данных, мы приводим значение к типу перечисления. Что если кто-то изменил данные в базе данных вручную и нарушил целостность данных, поэтому наше приведение не удалось?

Другим примером может быть случай, когда тип данных в c # имеет меньший диапазон, чем эквивалентное поле в базе данных. Если кто-то подставит значение в это значение вручную, скажем, к максимальному значению базы данных, тогда приложение выкинет исключение из диапазона.

Должны ли мы и как обрабатывать это исключение?

Редактировать: Поскольку большинство ответов схожи, я перефразирую вопрос. Подразумевается, что в приложении происходит регистрация исключений. Проблема заключается в том, что когда пользователь запрашивает некоторые данные и данные повреждены (не из операций CRUD приложения, а извне), преобразование данных из базы данных в модель не удастся, и пользователь вообще не получит данные. Допустимо ли иметь такое состояние в приложении, поскольку само приложение его не вызывало?

Проверка данных создаст большое замедление при извлечении данных. Представьте, что вам нужно проверять каждое десятичное значение, если оно выходит за пределы диапазона?

Answer 1

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

Если было бы "невозможно доказать", что странное значение попадет в вашу базу данных, можно утверждать, что такая проверка не нужна.Например, вы можете наложить ограничение на столбцы в столбцах базы данных.Даже в этом случае можно в любом случае сохранить проверки кода как защитную меру, если только вы не можете утверждать, что такие проверки ухудшают производительность вашей системы (чего, скорее всего, нет).

Answer 2

Я всегда считал стандартной практикой помещать любой код взаимодействия с базой данных в слой данных с блоками try...catch, чтобы вы могли цивилизованно обрабатывать такие ситуации.

Я непроверяйте каждую возможность, но возможность регистрировать исключения окажется полезной при поддержке вашего кода в долгосрочной перспективе.

В случае работающей системы всегда полезно иметь такую ​​информацию, особенно когда вы можете обвинить клиентавозиться с вещами, которых у них не должно быть.

edit

Как я уже говорил, вы не можете проверять каждую возможность, но вы можете перехватывать исключения, вызванные ситуацияминапример приведение значения к перечислению, которое не существует.

На самом деле невозможно проверить значения, выходящие за пределы диапазона, кроме предела, например, поле неожиданно возвращается как DBNull или не удается преобразовать тип данных базы данных в тип данных модели.В таком случае обработка ошибки и представление пользователю сообщения об ошибке или индикатора типа «VALUE UNKNOWN» должны быть в порядке.

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

Возможно, вы уже внедрили IDataErrorInfo в своей модели данных, специально для проверки ввода пользователя, если не посмотрите здесь в качестве примера, или, возможно, что-то подобное.

Но вы не можете справиться с тем, что «поврежденные» данные являются действительными значениями, т. Е. Если ваше поле enum было изменено на правильное значение, но логически неверное, вы не узнаете, пока не воспользуетесь им, что оно неверное.

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

Но, говоря:ошибка, пожалуйста, свяжитесь с вашим системным администратором "или что-то подобное, на мой взгляд, вполне приемлемо.

Answer 3

Зависит от того, что это обычно возможно?

В моем случае я делаю следующее:

1. Записываю все, что выполняет исполняемый файл (это может быть полезно дляв этом случае, чтобы определить, где произошел сбой)
2. При запуске его с командным файлом, проверьте состояние выхода, если это не 0 (произошла ошибка), отправьте мне электронное письмо!

При этом я знаю, если что-то случилось, и я могу доказать, что это не моя вина.

---

Что касается вашего обновления, я просто могу сказать, что это зависит!

В моемВ этом случае я строю проекты с учетом функциональных данныхИ во всех проектах у нас есть набор требований, которые клиент должен одобрить (например, данные из таблицы определенным образом).

Клиент принимает требования и вуаля!Так что, если что-то изменилось, это не наша вина, и мы защищены, потому что клиент принимает требования.