您是否应该在数据库级别和应用程序级别强制执行约束? [英] Should you enforce constraints at the database level as well as the application level?

问题描述

我一直在阅读 Dan Chak 的Enterprise Rails"一书，它让我思考:您是否认为应该在数据库级别和应用程序级别都设置数据约束?或者您是否觉得与 Ruby on Rails 等固执己见的框架类似 - 数据库只是数据的愚蠢存储库"，并且所有检查都应该在您的应用程序中完成(我不是想在这里挑出 RoR - 我是一个我自己是 Rails 的忠实粉丝，但我不同意它的数据库方法)?

I've been reading the book "Enterprise Rails" by Dan Chak and it got me thinking: Do you feel that you should have data constraints at both the database level and the application level? Or do you feel similarly to opinionated frameworks like Ruby on Rails - the database is just a "dumb repository" for data, and all checks should be done in your application (I'm not trying to single out RoR here - I'm a huge fan of Rails myself, but I disagree with its approach to the database)?

就我个人而言，我认为您应该同时拥有它们，以确保您的数据库和应用程序的安全性良好.我的意思是，您应该使用非空约束，如果已知，则给您的字段一个长度(而不是将它们全部保留在 nvarchar(255) 中)，具有诸如 数据库上的外键、检查约束和触发器，然后还通过应用程序中的业务逻辑规则强制执行此操作.IMO 这使您的应用程序通过其用户界面变得健壮，并且还可以防止可能直接访问数据库的人.

Personally, I feel that you should have them both in order to make sure your database and application are well-secured. What I mean is that you should make use of not-null constraints, give your fields a length if known ( as opposed to leaving them all at nvarchar(255) ), have things such as Foreign Keys, Check Constraints and Triggers on your database, and then also enforce this through business logic rules in your application. IMO this makes your application robust through its user interface, and also secure against someone who might have direct access to the database.

我最常看到的反驳论点是，它需要相当于重复逻辑的东西；一次在数据库级别，一次在应用程序级别 - 假设您有一个检查约束来验证是否输入了产品的 SKU(即它的长度大于零).

The counter-argument I most often see is that it requires what amounts to duplicate logic; once at the database level, and once at the application level -- Let's say you have a check constraint to verify that a product's SKU is entered (i.e. it's length is greater than zero).

您现在还需要在业务逻辑中包含验证方法，以确保用户输入的值的长度大于零，并且可能还需要一些客户端 Javascript 以在用户键入数据时捕获错误.

You would now need to also include validation methods in your business logic to make sure the value the user entered has a length greater than zero, and also possibly some client-side Javascript to catch the error as the user types data.

我并不认为这是一件坏事 - 是的，您有一些重复的逻辑，但最终结果是数据库作为堡垒"的心态，因为如果您考虑一下，您的数据是其中最重要的部分你的申请;毕竟，如果数据很容易被破坏和泄露，那么您闪亮的新 Web 2.0 应用程序有什么用?

I for one do not see this as a bad thing - yes you have some duplicate logic, but the end result is the "database as fortress" mindset, since if you think about it your data is the single most important part of your application; after all, what good is your shiny new Web 2.0 application if the data can easily be corrupted and compromised?

您对此有何看法?数据库应该是像诺克斯堡那样坚不可摧的堡垒，还是由激光守卫的开放式保险箱?换句话说，您是应该牺牲一些逻辑重复来确保安全的数据模型，还是将一切都留给您的应用程序并仅使用数据库来存储数据?

What are your thoughts on this? Should the database be an impenetrable fortress like Fort Knox, or an open safe that's guarded by lasers? In other words, should you sacrifice some duplication of logic to ensure a secure data model, or leave everything to your application and use the database simply to store data?

推荐答案

简而言之:数据库应该强制约束.

为什么:

1. 更容易.例如.要在特定数据列上设置约束，只有一个地方可以设置它:列本身.数据可能来自各种来源，但检查会放在数据最终存放的地方.
2. 完整性.数据库应对其托管的数据负责.不一致的数据库与没有数据库一样好.
3. 灵活性.新的 UI 开发环境太频繁了.如果数据库举手说会处理约束，前端开发和功能测试就容易多了.

1. Easier. For ex. to have a constraint set on a particular data column there is only one place to set it : the column itself. The data might come from various sources but the check is put where the data is finally put to rest.
2. Integrity. Database should be responsible for the data it hosts. An inconsistent database is as good as no database.
3. Flexibility. New UI development environments come all too frequently. If database puts up its hand to say that it will take care of the constraints , the front end development and functional testing are easier.

这篇关于您是否应该在数据库级别和应用程序级别强制执行约束?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！