我再次遇到有关业务逻辑放置位置的讨论：在应用程序代码中的业务层中，或者在存储过程方面数据库中。我个人倾向于采用第一种方法，但我希望首先听到你的意见，而不会影响你的个人观点。我知道不存在一个通用的解决方案，它通常取决于很多因素，但我们可以讨论这个问题。
顺便说一下，我们处于Web应用程序（拥有Oracle DB）的环境中，我们目前的方法是
然而，许多人倾向于将业务层内容（特别是关于验证）从存储过程转移到DB。
你怎么看？我想讨论一下。
答案 0 :(得分：2)
无论某人使用您的应用程序，其他应用程序或SQL工具本身是否有价值，数据都能保持正常。
有一个永远不应该为NULL的值吗？ - 好，设计数据库来执行该规则。在应该始终存在的两个表之间有关系吗？ - 好，把外键约束放在。
在问题域中获得的值应该是唯一的吗？ - 好，放一个独特的约束。有一个字符串应该总是在6-10个字符之间？ - 好，添加一个检查约束。
这些都是基本的，易于添加到数据库中，并且当您尝试从数据库中加载某人手动损坏的内容时，您可以放心地确定应用程序不会失败。在某种程度上，它们可以被视为业务逻辑。 （毕竟，你是从关于你的问题领域的具体事实中得出所有这些）。
所以在这个程度上，我会把那种的业务逻辑放在数据库中。是的，在您的应用程序中，您需要应用类似的检查，以提供更愉快的用户体验。但是，当我试图将无效的东西放入数据库而不是在6个月后发现这个事实时，我宁愿让我的应用程序失败（作为最后的手段）。
答案 1 :(得分：1)
数据库中的逻辑是维护的噩梦。在真正需要的时候，应该把它记录得非常好，并将其与其他源代码一起放在文本格式中。
答案 2 :(得分：1)
我只看过一个案例，其中存储过程中的逻辑是有意义的;基本上它与性能有关：大量数据移动和紧缩。拯救的恩典是逻辑不是非常复杂 - 但SP仍然是一场噩梦。在应用程序代码中执行它太慢了。
所以猜测 - 那可能是50+项目中的1个？
你定义的因素将是：
答案 3 :(得分：0)
由于各种原因，它通常很糟糕。如果你以面向对象的方式工作，那么存储过程并不是eaxactls逻辑的好地方 - 因为你的对象不再存在了。对象可以在多个表中。
二。 SQL是编写复杂逻辑的一个非常糟糕的语言。它只是没有用 - 这是SQL Server允许SP用.NET编写的一个原因。尝试在SQL中计算哈希，你就会理解我的意思 - 各种字符串操作都是另一个领域。肮脏的地狱。
一般情况下，SP通常是以愚蠢的论据来完成的。像人们为捍卫他们所提出的论据那样的白痴根本就不是真的。弗兰斯·布尔马（Frans Bourma）列出了最常用的谬误和一个很好的解释，为什么这些论点在http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx都是愚蠢的谣言 - 是的，正是这种程度的愚蠢（就像人们甚至没有阅读文档或思考他们的内容）实际上，在所有后果中说。）我个人对存储过程的系统有限，而我所拥有的系统是：复杂性有限，但性能很高。基本上没有继承，因为对象模型很简单，SP中的事务逻辑不是太复杂而且我需要/想要极小的锁定速度，因此某些操作被移动到存储过程中。最重要的是，这个特定的应用程序也有一个非常不寻常的对象模型（对象从各种源动态流式传输，永远不会更新，总是被替换，并且所有更改都必须通过服务而不是在对象上完成 - 有时因为更改是在另一个国家的另一个国家的另一台计算机上“要求”。
一个很好的例子是一个高绩效的会计系统（因为它跟踪来自全自动交易系统的交易）。每个SP中的逻辑并不是很复杂，但我希望尽可能少地使用SQL。
现在，存储过程的不良方面也是很有用的工具。没有适当的测试框架，没有嘲讽的框架，源代码控制itnegration有点尴尬（但可以使用正确的工具集）。综合调试？好吧，非常感谢Microsoft和Visual Studio - 它确实有效（存储过程中的断点 - 非常好）。
我还没有看到一种使用大量存储过程的方法，而这些存储过程并没有完全被证明 - 在实际上是“员工应该被解雇”的思维水平。也许他们在那里，但我还没有看到他们。