Где выполнить проверку данных для настольного приложения? В базе данных или в коде?

Question

В однопользовательском настольном приложении, которое использует базу данных для хранения, необходимо ли выполнять проверку данных в базе данных, или это нормально делать в коде? Каковы лучшие практики, и если их нет, каковы преимущества и недостатки каждой из двух возможностей?

Answer 1

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

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

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

- edit (дополнительная информация добавляется из комментариев) -

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

Answer 2

Вы оба.

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

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

Подводя итог, вы делаете оба из:

1. Санировать и проверять вводимые пользователем данные, прежде чем они попадут в ваше хранилище данных.
2. Снабдите ваше хранилище данных ограничениями, которые укрепят ваши проверки.

Answer 3

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

Answer 4

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

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

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

Answer 5

Не было бы разумно проверить данные, прежде чем пытаться их сохранить? Соединения с базой данных и ресурсы дороги. Постарайтесь убедиться, что у вас есть какая-то логика для проверки данных перед отправкой в ​​базу данных. Я видел, как некоторые люди делали это на переднем крае, другие на заднем, другие даже оба.

Может быть хорошей идеей создать уровень сборки или проверки. Проверьте данные и отправьте их в базу данных.

Answer 6

В приложении пожалуйста!

Очень трудно перевести sqlerror -12345 в сообщение, которое что-либо значит для конечного пользователя. Во многих случаях ваш пользователь может уже давно исчезнуть к тому времени, когда база данных получит данные (например, я нажму «Отправить», затем посмотрите, сколько голосов «за» я получил сегодня в stackoverflow).

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

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

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