存储库中的业务规则？
我们假设应用程序在模型/表示层中具有所有必要的业务规则，并且它们工作正常。我的问题之一是，是否应该在像 SQL Server 这样的存储库中使用冗余业务规则（即两个日期的跨度不能与任何其他现有跨度重叠）。
在 SQL Server 中添加强制执行此规则的约束是否有必要/有益？一方面，它可以防止任何人（包括 DBA）在绕过应用程序时无意中违反业务规则。此外，我们已经通过主键和外键在存储库中拥有某种形式的业务规则。另一方面，重复的规则需要额外的时间来开发和维护。
这个问题涉及许多不同的技术，因此我故意保持标签通用。
Let's assume that an application has all necessary business rules in the model / presentation layer and that they work fine. My question is one of whether or not redundant business rules (i.e. a span of two dates cannot overlap any other existing spans) should be used in a repository like SQL Server.
Is it necessary/beneficial to add a constraint in SQL Server that enforces this rule? On the one hand, it prevents anyone (including DBAs) from inadvertantly breaking business rules when they bypass the application. In addition, we already have some forms of business rules in the repository via primary and foreign keys. On the other hand, the duplicated rules require additional time to develop and maintain.
This question spans many different technologies so I intentionally kept the tags generic.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
如果您关心您的数据，您将优先将所需的规则放在那里，而不是其他任何地方。数据受到应用程序之外的许多地方的影响。仅将规则放在业务层是短视的做法，并且会导致严重的数据完整性问题，并且很难修复。有关数据的规则属于数据库。
If you care about your data, you will put the required rules there in preference to anywhere else. Data is affected from many places beyond the applciations. Putting rules only inthe business layer is short-sighed and leads to serious data integrity issues atat can be horrible to try to fix. Rules concerning the data, belong in the database.
您通常会发现在多个位置手动维护业务规则非常困难。
我在一些项目中充分利用了代码生成，从需求模型生成某些类型的规则。例如，我可能有“名字不得超过 50 个字符”的要求。我以结构化方式在 UML 中对该需求进行建模，然后生成 UI 代码以将输入限制为 50 个字符，业务逻辑以强制执行相同的限制（永远不要相信 UI！），并生成 DDL/ORM 映射文件以指定中的列宽度数据库。
同样的想法可以扩展到建模更复杂的规则，并在应用程序的每一层中生成适当的执行代码。
You will generally find it very difficult to maintain business rules in multiple places by hand.
I have made good use of code generation on some projects to generate some types of rules from requirement models. For example, I might have the requirement "First name shall not exceed 50 characters". I model that requirement in UML in a structured manner, then generate UI code to cap the input at 50 characters, business logic to enforce that same limit (never trust the UI!), and DDL/ORM mapping file to specify the column width in the DB.
That same idea could be extended to model more complex rules, and generate appropriate enforcement code into each layer of the application.
业务规则还是数据完整性规则？
我的经验（主要是大公司，我们这里不是在谈论软件公司或业余爱好商店）是，您的数据库将比应用程序更耐用。最终让其他应用程序与之对话。如果没有适当的规则（无论何种类型），某个地方的某个人就会破坏数据库。
Business rule or data integrity rule?
My experience (mostly large corporate, we're not talking software house or hobby shop here) is that your database will outlast the application. And eventually have other apps talking to it. And someone, somewhere will break the database if it has no rules (of whatever kind) in place.
你自己说过......什么在后门上强制执行业务规则（即DBA戳数据）。如果你担心这种情况会发生，那就付出代价。如果没有，则将其保留，这样其他地方执行的规则就不会多余。
You said it yourself... what enforces the business rules on the back door (i.e. the DBA poking data). If you fear this will happen, then pay the price. If not, then leave it off so the rules enforced elsewhere will not be redundant.
取决于您的应用程序 - 如果打算与数据库无关，请将逻辑保留在应用程序代码中。否则，业务规则更适合数据库。
Depends on your application - keep the logic in the application code if it's intended to be db agnostic. Otherwise, the business rules are better suited in the database.