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

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

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

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

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

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

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

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

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

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

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

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

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

Можно привести доводы в пользу:

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

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

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

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

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

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

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

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

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

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

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

Это не исключает проведения первоначальной проверки на более высоких уровнях,

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

Другой вариант: каковы школы мысли на этом? Различаются ли они в зависимости от сектора или технологии?

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

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

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

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

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

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

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

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