Действительно ли хорошо использовать проверочные ограничения для бизнес-правил
Можно ли вытянуть некоторый порядковый номер производителя или метку?
Наш магазин является магазином Dell, таким образом, мы используем метку, которая уникальна для каждой машины для идентификации их. Я знаю, что это может быть запрошено от BIOS, по крайней мере, в Linux, но я не знаю бесцеремонно, как сделать это в Windows.
6 ответов
Да, проверочные ограничения - допустимый инструмент для бизнес-правил.
Но уверены ли вы, что вам нужно использовать проверочные ограничения или использовать вспомогательную таблицу с отношениями внешнего ключа? Если вы обнаружите, что определяете похожие контрольные ограничения в разных местах - ответ - да, это определенно должна быть вспомогательная таблица
Целостность данных является ключевым фактором; нет особой ценности для системы, которая позволит человеку хранить то, что не соответствует бизнес-правилам, если приложение обходится. Это также значительно облегчает жизнь, если логика находится в базе данных для ситуаций, когда исходное приложение написано на C #, и высшие руководители решили, что рынку нужна версия Java / Ruby / Python / и т. Д.
ДА, это хорошо!
Вам действительно следует всегда проверять свои бизнес-правила как в коде вашего приложения (на бизнес-уровне), так и, если это вообще возможно, в вашей базе данных.
Почему? Представьте, что кому-то удается отправить некоторые данные в вашу базу данных без использования вашего приложения - если у вас есть ваши чеки только в приложении, эти проверки не применяются.
Если у вас тоже есть проверки в базе данных, вы можете убедиться, что данные в базе данных соответствуют, по крайней мере, тем простым проверкам, которые можно сформулировать в SQL CHECK CONSTRAINTS.
Обязательно используйте их! Вам нужно постараться сохранить качество данных на максимально высоком уровне - добавив ссылочной целостности, проверка ограничений, уникальных ограничений и т. д. в базе данных поможет вам в этом.
Не не полагайтесь только на свое приложение!
Вы обязательно должны использовать ограничения CHECK там, где это возможно, но я бы также не стал этого делать. Если нет возможности получить данные в вашу базу данных без использования ваших приложений, вы можете быть в безопасности с минимальными ограничениями CHECK и тяжелой бизнес-валидацией.
Может быть довольно сложно определить строгие бизнес-правила в SQL. Придерживайтесь проверки данных в базе данных и фактических бизнес-правил в своем приложении.
Кроме того, постарайтесь организовать схему таким образом, чтобы затруднять ввод неверных данных с внешними ключами и т.п.
Чем более «умной» будет ваша база данных, тем надежнее будет целостность содержащихся в ней данных. Так что да, я думаю, что это хорошо и важно для реализации.
Это дает множество преимуществ: вы можете гарантировать безопасность своих данных, если существует несколько приложений, изменяющих данные (например, приложение C # + Веб-приложение + Мобильное приложение ...), и это позволит вам меньше работать в этих "второстепенных" приложениях. Если всю работу выполняет база данных, приложения являются только интерфейсом для базы данных.
В будущем будет проще переносить приложения, но будет сложнее переносить базу данных. Это важное решение.
Зависит от ограничений
- Зависит от ограничений
- Вам также следует попытаться избежать (если возможно) проверки одного и того же ограничения в двух местах - это будет означать, что существует дублированный код в вашей системе, что приводит к ненужной сложности.
Есть некоторые ограничения, которые можно и нужно применять в базе данных, например, ограничения внешнего ключа и уникальность. База данных сможет применять их быстро и эффективно.
Другие более сложные «бизнес-ограничения» лучше применять на уровне бизнес-логики. Примерами этого могут быть «клиент должен иметь подтвержденный адрес электронной почты, прежде чем разрешить покупку». Их было бы сложно и обременительно применять в базе данных - вы рискуете написать свою систему на SQL, что является плохой идеей.
C #. В C # гораздо проще повторно использовать логику, чем в SQL (по моему опыту), и поддерживать ее в целом.