Зачем повторять ограничения базы данных в моделях?

Question

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

Я понимаю преимущество проверки JS, но я считаю, что проверка модели делает дополнительную поездку в БД. Я на 100% уверен, что в БД выполняются определенные проверки, поэтому проверка модели будет просто избыточной.

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

Answer 1

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

Answer 2

Не забывайте о переносимости. Обеспечение проверки в модели поддерживает независимость базы данных вашего приложения. Вы можете запрограммировать приложение для базы данных SQLite, а затем развернуть его на MySQL ... о, подождите, у вас его нет ... PostgreSQL? Нет? О, Оракул, хорошо.

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

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

@ le dorfier

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

Реляционная алгебра, как правило, считается "выразительно полной" (мне даже говорили, что есть формальное доказательство того, что RA плюс TC является завершением по Тьюрингу). Следовательно, RA (плюс TC) может выражать «все, что неправильно» (неправильно в том смысле, что оно нарушает некоторые / любые произвольные «бизнес-правила»).

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

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

@ Брэдли Харрис.

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

Answer 7

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

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