Нужно ли проверять данные на уровне базы данных?

Question

Я пишу некоторые хранимые процедуры для создания таблиц и добавления данных. Одним из полей является столбец, который указывает процент. Значение там должно быть 0-100. Я начал думать: «Где должна проводиться проверка данных? Где вообще должна проводиться проверка данных? Это индивидуальная ситуация?»

Мне приходит в голову, что, хотя сегодня я решил, что 0-100 является действительным значением для процента, завтра я могу решить, что любое положительное значение является допустимым. Так что это может быть бизнес-правилом, не так ли? Следует ли реализовать бизнес-правило на уровне базы данных?

Просто ищите руководства, у нас здесь больше нет базы данных.

Answer 1

Обычно я выполняю проверки в нескольких местах:

1. Клиентская сторона, использующая валидаторы на странице aspx
2. Проверки на стороне сервера в коде

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

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

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

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

Answer 2

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

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

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

Answer 3

В общем, я думаю, что чем ближе валидация к данным, тем лучше.

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

Answer 4

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

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

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

Вы не упомянули, какая версия SQL Server, но вы можете посмотреть на определенные пользователем типы данных и посмотреть, поможет ли это вам, поскольку вы можете просто централизовать проверку.

Answer 5

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

Answer 6

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

Answer 7

Можно сделать чехол для:

• В реализации базы данных достаточно для обеспечения общей целостности данных (например, в SO это может быть каждый вопрос / ответ, по крайней мере, с одной ревизией).

• На границе между уровнем представления и бизнес-логики убедитесь, что данные имеют смысл для бизнес-логики (например, в SO обеспечение разметки не содержит опасных тегов)

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

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

Answer 8

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

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

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

Answer 9

Ричард прав: вопрос субъективен в том виде, в котором он был задан здесь.

Еще один вариант: что это за идеи? Они различаются по секторам или технологиям?

Я немного занимался Ruby on Rails, и там даже отношения между записями (один ко многим и т. Д.) НЕ соблюдаются на уровне БД, не говоря уже о каскадном удалении и прочем. Также нет каких-либо ограничений помимо основных типов данных, которые позволяют БД выполнять свою работу. Ваша процентная доля обрабатывается не на уровне базы данных, а на уровне модели данных.

Так что я думаю, что одной из тенденций, которые мы наблюдаем в последнее время, является придание большей мощности уровню приложений. Вы ДОЛЖНЫ проверить данные, поступающие на ваш сервер (поэтому где-то на уровне представления), и вы МОЖЕТЕ проверить их на клиенте, и вы МОЖЕТЕ проверить еще раз на бизнес-уровне вашего приложения. Почему вы хотите проверить это снова на уровне базы данных?

Однако: происходят самые страшные вещи, и иногда БД получает значения, которые «невозможны» при чтении кода бизнес-уровня. Поэтому, если вы управляете, скажем, финансовыми данными, я бы сказал, что нужно вводить все возможные ограничения на каждом уровне. Что делают люди из разных секторов?

Answer 10

Если ваш процент всегда «часть, деленная на целое» (и вы не сохраняете значения части и целого в другом месте), тогда проверка его значения по [0-100] подходит на уровне дБ. Дополнительные ограничения должны применяться на других уровнях.

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

Это индивидуальная ситуация. Обычно на уровне БД следует проверять только те ограничения, которые никогда не могут изменяться или имеют естественные ограничения (как в первом примере).