我一直在我的应用程序层(模型)和数据库层(引发错误的存储过程)中执行业务规则。
出于以下几个原因，我一直在这两个地方重复我的验证:
- 如果条件发生变化 当他们被检查时 应用程序代码以及何时 在数据库中检查， 数据库中的业务规则检查 将挽救这一天。数据库 还允许我锁定各种 以比在更简单的方式记录 我的应用程序代码，看起来 自然会在这里这样做。
- 如果我们有 做一些批量数据 直接插入/更新数据库，如果我路由 所有这些操作都通过我 存储过程/函数 正在执行业务规则 验证，我没有机会 即使我缺乏通过应用程序进行单一输入时会获得的保护，也会输入错误数据。
- 同时 只在 数据库会产生同样的效果 实际数据看来 不恰本地把数据扔到 数据库先做好 努力验证它符合 约束和业务规则。
什么是正确的平衡？
最佳答案
您需要在数据层强制执行以确保数据完整性。这是您的最后一道防线，也是数据库的工作，以帮助加强其数据世界观。
也就是说，将垃圾数据扔给数据库进行验证是一种粗略的技术。通常，错误被设计为人类可读而不是机器可读，因此程序处理来自数据库的错误并从中找出正面或反面的效率很低。
存储过程是另一回事。过去，存储过程是处理数据层等业务规则的方式。
但是今天，随着现代应用程序服务器环境的出现，它们通常成为放置此逻辑的更好位置。它们提供多种方式来访问和公开数据(Web、Web 服务、远程协议(protocol)、API 等)。此外，如果您的规则占用大量 CPU(可以说大多数不是)，则扩展应用程序服务器比扩展数据库服务器更容易。
应用程序服务器中的大量功能为它们提供了超出数据库服务器所能做到的灵 active ，因此，许多曾经被推回数据库的内容正在被拉出，数据库服务器被降级为“哑巴”坚持”。
也就是说，使用存储过程等肯定有性能优势，但现在这是一个调整问题，问题变成了“为了我们通过将其放入数据库服务器获得的 yield 而失去应用程序服务器功能是否值得” .
关于应用服务器，我不是简单地谈论 Java，而是 .NET 甚至 PHP 等。
关于database - 业务规则应该同时在应用层和数据库层执行，还是只在两者之一执行？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4217100/