Хорошо ли использовать проверочные ограничения для бизнес-правил?

Question

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

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

Answer 1

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

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

Целостность данных является ключевой; система, которая позволит человеку хранить что-то, что не соответствует бизнес-правилам, в случае обхода приложения, не имеет особой ценности. Это также делает жизнь намного проще, если логика в базе данных для ситуаций, когда исходное приложение находится на C #, и руководители решили, что рынку нужна версия Java / Ruby / Python / etc.

Answer 2

ДА, это хорошо!

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

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

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

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

Не не полагайтесь только на свое приложение!

Answer 3

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

Может быть довольно сложно определить строгие бизнес-правила в SQL. Придерживайтесь проверки данных в базе данных и реальных бизнес-правил в вашем приложении.

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

Answer 4

C #. Гораздо проще повторно использовать логику в C #, чем SQL (по моему опыту) и вообще поддерживать.

Answer 5

Зависит от ограничений

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

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

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

Answer 6

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

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

В будущем будет проще перенести приложения, но будет сложнее перенести базу данных. Это важное решение.