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

Question

Я читал книгу «Enterprise Rails» Дэна Чака, и это заставило меня задуматься: считаете ли вы, что у вас должны быть ограничения данных как на уровне базы данных, так и на уровне приложения? Или вы чувствуете себя аналогично самоуверенным фреймворкам, таким как Ruby on Rails - база данных является просто «тупым хранилищем» данных, и все проверки должны выполняться в вашем приложении (я не пытаюсь выделить здесь RoR - я Огромный фанат Rails сам, но я не согласен с его подходом к базе данных)?

Лично я чувствую, что вы должны иметь их обоих, чтобы убедиться, что ваша база данных и приложение хорошо защищены. Я имею в виду, что вы должны использовать ненулевые ограничения, дать вашим полям длину, если она известна (вместо того, чтобы оставлять их все в nvarchar (255) ), иметь такие вещи, как Foreign Ключи , Проверяют ограничения и Триггеры в вашей базе данных, а затем применяют это с помощью правил бизнес-логики в вашем приложении. IMO это делает ваше приложение надежным через его пользовательский интерфейс, а также защищает от кого-то, кто может иметь прямой доступ к базе данных.

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

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

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

Что вы думаете об этом? Должна ли база данных быть неприступной крепостью, такой как Форт Нокс, или открытым сейфом, который охраняют лазеры? Другими словами, следует ли вам пожертвовать некоторым дублированием логики для обеспечения безопасной модели данных или оставить все для вашего приложения и использовать базу данных просто для хранения данных?

Answer 1

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

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

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

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

Answer 2

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

Даже если вы проверяете все, создавая ограничения, как вы собираетесь показывать пользователю свои ошибки проверки? Как ответы от базового движка БД? Даже для поддержки ответов API, это отличная идея, чтобы отобразить эти ответы БД на что-то более значимое с точки зрения API. Возврат «Отказано в доступе» вместо «Запись не найдена».

Предположим, все 3 стороны: клиент, API и БД. Внедрите Client, потому что это необходимо для хорошего UX и снижения нагрузки на сервер. Сделал БД вторым, чтобы все данные были ограничены. Внедрить валидацию API (на стороне сервера), чтобы сделать все сообщения различимыми для пользователей API (Отказ от ответственности: я не пиарщик сообщества Node, но даже неплохо использовать сервер Node.js, чтобы вы могли повторно использовать свою сторону клиента проверочный код).

Answer 3

Я согласен, что ответ на этот вопрос зависит от окружающей среды.

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

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

Answer 4

Это зависит.

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

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

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

Кроме того, вы должны объявить ограничение «ссылки» для каждого внешнего ключа. Это обеспечивает ссылочную целостность. При наличии достойной СУБД вы должны быть в состоянии обеспечить ссылочную целостность, даже если внешний ключ является необязательным, другими словами, он может иметь значение NULL. NULL, конечно, ни к чему не относятся.

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

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

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

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

Answer 5

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

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