blocks|key|1088160|text|更快的响应时间，更少的数据库负载。离客户端越远，你就可以进行验证，比如JavaScript，速度就越快。主要的缺点是必须在多个层中实现相同的规则。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1088161|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Quicker response times, less database load. The further out to the client you can do validation, i.e. JavaScript, the quicker it is. The major con is having to implement the same rules in multiple layers.

blocks|key|3404429|text|你可能获得的任何好处都可能会被重复维护约束的麻烦所抵消。除非您碰巧有一种简单的机制来在单个位置指定它们并使它们保持同步，否则我建议您坚持使用另一个位置。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3404430|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

Just about any benefit that you might gain would probably be canceled out by the hassle of maintaining the contraints in duplicate. Unless you happen to have an easy mechanism for specifying them in a single location and keeping them in sync, I would recommend sticking with one location of the other.

blocks|key|1140213|text|如果数据库约束是由一个人编写的，而代码的其余部分是由另一个人编写的，那么他们确实不应该完全信任对方。检查边界上的东西，特别是如果它们代表组织-人的边界。例如，用户到应用程序或一个开发人员模块到另一个，或者一个公司部门到另一个公司部门。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1140214|entityMap^0|0^^$0|@$1|2|3|4|5|6|7|D|8|@]|9|@]|A|$]]|$1|B|3|-4|5|6|7|E|8|@]|9|@]|A|$]]]|C|$]]

If database constraints are coded by one person and the rest of the code is code by another, they really shouldn't trust each other completely. Check things at boundaries, especially if they represent organizational-people boundaries. e.g. user to application or one developers module to another, or one corporate department to another.

blocks|key|4873251|text|理想情况下，模型的设计应该放在第一位(基于用户故事、用例等)其中数据库模式是从模型派生的。然后，可以从模型生成数据库实现(显式地将两者都绑定到单个源)，或者可以基于关系完整性要求(在概念上与模型不同，并且通常具有与模型不同的粒度和词汇表，尽管在许多情况下存在某种映射)来设计数据库约束。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4873252|我通常只考虑数据库约束的关系完整性要求。在很多情况下，业务约束的粒度和通用适用性比数据库设计人员所知道的更加不一致、短暂和细粒度；而且它们会随着时间和应用程序模块的变化而变化得更频繁。|4873253|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Ideally the design of the model should come first (based on user stories, use cases, etc.) with the database schema deriving from the model. Then the database implementation can either be generated from the model (explicitly tying both to a single source), or the database constraints can be designed based on relational integrity requirements (which are conceptually different from, and generally have a different granularity and vocabulary than, the model, although in many cases there is a mapping of some kind.

I generally have in mind only relational integrity requirements for database constraints. There are too many cases where the granularity and universal applicability of business constraints are too incongruent, transitory, and finer-grained than the database designer knows about; and they change more frequently over time and across application modules.

blocks|key|1088270|text|@+le+dorfier|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1088271|数据完整性问题和业务规则问题是一回事(对必要的过程性“业务规则”内容进行模块化处理，例如“当进入新客户时，必须将具有某某内容的邮件发送到该客户的电子邮件地址”)。|1088272|关系代数通常被认为是“表达完备的”(我甚至被告知有正式的证据证明RA加TC是图灵完备的)。因此，RA+(加上TC)可以表达“所有错误的东西”(在某种意义上是错误的，因为它违反了一些/任何任意的“业务规则”)。|1088273|因此，实施“错误的事物集必须保持为空”的规则归结为dbms为您实施每个可能的(与数据相关的，即与状态相关的)业务规则，而无需任何程序员编写代码的第一个字节来实现这种业务规则实施。|1088274|您提出了“业务规则频繁更改”作为论据。如果业务规则更改，那么允许系统最快地适应这样的业务规则的场景是什么:只需更改强制执行约束/业务规则的RA的相应表达式，或者必须在应用程序代码中的何处强制执行规则并必须全部更改？|1088275|@+bradley+harris。|1088276|对，是这样。如果我可以投票的话，我会投你的票。但是您忘了提到，因为人们永远不能真正确定某个数据库永远不会被其他应用程序所需要，所以执行业务规则的唯一明智的地方是在DBMS中。|1088277|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|Q|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|R|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|S|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|T|8|@]|9|@]|A|$]]|$1|J|3|K|5|6|7|U|8|@]|9|@]|A|$]]|$1|L|3|M|5|6|7|V|8|@]|9|@]|A|$]]|$1|N|3|-4|5|6|7|W|8|@]|9|@]|A|$]]]|O|$]]

@ le dorfier

Matters of data integrity and matters of business rules are one and the same thing (modulo the kind of necessarily procedural "business rules "stuff such as "when a new customer is entered, a mail with such-and-so content must be sent to that customer's email address).

The relational algebra is generally accepted to be "expressively complete" (I've even been told there is formal proof that RA plus TC is Turing complete). Therefore, RA (plus TC) can express "everything that is wrong" (wrong in the sense that it violates some/any arbitrary "business rule").

So enforcing a rule that "the set of things that are wrong must remain empty" boils down to the dbms enforcing each possible conceivable (data-related, i.e. state-related) business rule for you, without any programmer having to write the first byte of code to achieve such business rule enforcement.

You bring up "business rules change frequently" as an argument. If business rules change, then what would be the scenario that allows for the quickest adaptation of the system to such a business rule : only having to change the corresponding expression of the RA that enforces the constraint/business rule, or having to go find out where in the application code the rule is enforced and having to change all that ?

@ bradley harris.

Correct. I'd vote you up if voting was available to me. But you forget to mention that since one can never be really certain that some database will never be needed by some other app, the only sensible place to do business rules enforcement is inside the DBMS.

blocks|key|1088282|text|CakePHP中的验证是在将保存或更新查询发送到数据库之前进行的。因此，它降低了数据库的负载。您认为模型验证需要额外访问数据库的想法是错误的。By+default,+validation+occurs+before+save.|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1088283|entityMap|0|LINK|mutability|MUTABLE|url|http://api12.cakephp.org/view_source/model/#line-1140^0|1Z|16|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@$A|M|B|N|1|O]]|C|$]]|$1|D|3|-4|5|6|7|P|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]]]

Validation in CakePHP happens before save or update query is sent to the database. Therefore it reduces the database load. You are wrong in your belief that the model validation makes an extra trip to the database. <a href="http://api12.cakephp.org/view_source/model/#line-1140" rel="nofollow noreferrer">By default, validation occurs before save.</a>

blocks|key|1088334|text|不要忘记可移植性的问题。在模型中强制验证使您的应用程序与数据库无关。您可以针对SQLite数据库对应用程序进行编程，然后部署到MySQL。哦，等等，你没有那个..PostgreSQL？不是吗？哦，先知，好吧。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1088335|此外，在生产中，如果在保存然后重定向的典型控制器操作中发生数据库错误，您的用户将无法盯着空白的白页(因为错误处于关闭状态，所以没有可输出的视图，并且重定向从未发生)。基本上，数据库错误在生产模式中是关闭的，因为它们可以深入了解DB模式，而模型验证错误仍然启用，因为它们是用户友好的。|1088336|但是，您有一个观点，是否有可能捕获这些数据库错误并对其执行一些有用的操作？目前没有，但如果CakePHP可以动态地将它们转换为失败的模型验证规则，防止我们重复自己，那就太好了。不同的数据库抛出不同的错误，因此每个DBO数据源都需要更新以支持它，然后才能发生错误。|1088337|entityMap^0|0|0|0^^$0|@$1|2|3|4|5|6|7|H|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|I|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|J|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|K|8|@]|9|@]|A|$]]]|G|$]]

Don't forget the matter of portability. Enforcing validation in the model keeps your application database-agnostic. You can program an application against a SQLite database, and then deploy to MySQL.. oh wait, you don't have that.. PostgreSQL? No? Oh, Oracle, fine.

Also, in production, if a database error happens on a typical controller action that saves and then redirects, your user will be stuck staring at a blank white page (since errors are off, there was no view to output, and the redirect never happened). Basically, database errors are turned off in production mode as they can give insight into the DB schema, whereas model validation errors remain enabled as they are user-friendly.

You have a point though, is it possible to capture these database errors and do something useful with them? Currently no, but it would be nice if CakePHP could dynamically translate them into failed model validation rules, preventing us from repeating ourselves. Different databases throw different looking errors, so each DBO datasource would need updated to support this before it could happen.

In a CakePHP application, for unique constraints that are accounted for in the database, what is the benefit of having the same validation checks in the model?

I understand the benefit of having JS validation, but I believe this model validation makes an extra trip to the DB. I am 100% sure that certain validations are made in the DB so the model validation would simply be redundant.

The only benefit I see is the app recognizing the mistake and adjusting the view for the user accordingly (repopulating the fields and showing error message on the appropriate field; bettering the ux) but this could be achieved if there was a constraint naming convention and so the app could understand what the problem was with the save (existing method to do this now?)

Why repeat database constraints in models?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

在CakePHP应用程序中，对于考虑到数据库中的唯一约束，在模型中使用相同的验证检查有什么好处？我理解使用JS验证的好处，但我相信这个模型验证会给数据库带来额外的麻烦。我100%确定在数据库中进行了某些验证，因此模型验证将是多余的。我看到的唯一好处是应用程序可以识别错误并相应地为用户调整视图(重新填充字段并在适当的字段...

问为什么要在模型中重复数据库约束？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问为什么要在模型中重复数据库约束？EN