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

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

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

Просто ища инструкции, у нас больше нет dba.

Ответ 1

Как правило, я делал проверки в нескольких местах:

Клиентская сторона использует валидаторы на странице aspx
Проверка на стороне сервера в коде

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

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

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

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

Ответ 2

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

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

Ответ 3

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

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

Ответ 7

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

Ответ 8

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

Ответ 9

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

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

Ответ 10

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

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

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

В небольшой организации (нет DBA ergo, small?), я бы поставил бизнес-правила, в которых у вас есть сильный опыт разработки.

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

Ответ 11

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

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

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

Ответ 12

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

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

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

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

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