我在全球三大IT咨询公司之一的一个项目中工作，一名DBA告诉我，公司的最佳实践的状态存储过程不是“最佳实践”。这与我学到的一切都太相反了。

存储过程为您提供代码重用和封装（软件开发的两个支柱），安全性（您可以为单个存储的proc授予/撤消权限），保护您免受SQL注入攻击并还有助于提高速度（尽管DBA表示从SQL Server 2008开始，即使常规SQL查询运行了足够的时间，它们也会被编译。

我们正在使用敏捷软件开发方法开发复杂的应用程序。任何人都可以考虑为什么不想使用存储的proc的充分理由吗？我的猜测是，DBA不想维护那些存储的proc，但是似乎有太多负面因素无法证明这种设计决策是正确的。

根据我从事大型项目的经验，您必须非常清楚业务逻辑的用途。如果您允许单个开发人员将业务逻辑放在他们认为合适的业务对象层或存储过程中的环境，那么大型应用程序将变得非常难以理解和维护。

存储过程对于加快某些数据库操作非常有用。我的体系结构决定是将所有逻辑保留在应用程序的业务层中，并以有针对性的方式采用存储过程来提高性能，以进行基准测试表明有必要。

一些观察

存储过程为您提供代码重用和封装（软件开发的两个支柱），

仅当您在应该使用它们的上下文中正确使用它们时。关于功能（在结构化编程中）或方法（在面向对象的编程中），可以说相同的主张，但是，我们看到了1K函数和兆资产对象。

工件不会给您带来这些好处。正确使用这些工件可以带来这些好处。

安全性（您可以授予/撤消对单个存储过程的权限），

是。这是一个好点，也是我喜欢存储过程的主要原因之一。与仅使用视图和用户帐户通常可以实现的访问控制相比，它们提供了更好的粒度访问控制。

保护您免受SQL注入攻击，

这不是特定于SP的，因为您可以通过参数化的SQL语句和输入清理获得相同级别的保护。但是，除了“深度安全性”问题之外，我还将使用SP 。

并且还有助于提高速度（尽管DBA表示，从SQL Server 2008开始，如果常规SQL查询运行了足够的时间，则它们也会被编译）。

这是特定于数据库供应商的，但是总的来说，您的DBA是正确的。确实会编译SQL语句（静态或参数化）。如果您希望/需要聚合和计算您无法使用简单的SQL语句完成的数据，但是与SQL紧密集成并且不保证往返于应用程序服务器，则SP可提供帮助。

一个很好的例子是将数据查询到一个或多个临时游标中，以便从中运行另一个SQL本身。您可以在应用服务器中以编程方式进行操作，也可以通过在数据库中进行操作来保存多次往返。

但是，这不应该成为常态。如果您遇到许多情况，则表明数据库设计不正确（或者您正在跨部门从不太兼容的数据库架构中提取数据）。

我们正在使用敏捷软件开发方法开发复杂的应用程序。

敏捷性与软件工程流程和需求管理有关，而与技术无关。

任何人都可以考虑为什么不想使用存储的proc的充分理由吗？

错误的问题

这个问题是错误的，等同于询问“是否有充分的理由不使用GOTO”？在这个问题上，我与尼克劳斯·沃斯（Niklaus Wirth）的支持远胜于迪克斯特拉（Dijkstra）。我可以理解Dijkstra的情绪来自何处，但我认为这并非在所有情况下均100％适用。与商店进程和任何技术相同。

如果工具可以很好地用于其预期目的，并且是完成特定任务的最佳工具，那么它就是好工具。否则使用它并不表示该工具是错误的，而是表明焊工不知道他/她在做什么。

正确的问题是“应避免使用哪种类型的存储过程使用模式”。或者，“在什么条件下我（或不应）使用存储过程”。寻找不使用技术的原因只是将责任归咎于工具，而不是将工程责任直接归咎于工程师。

换句话说，这是一种无知或无知的声明。

我的猜测是，DBA不想维护那些存储的proc，但是似乎有太多负面因素无法证明这种设计决策是正确的。

然后，他们正在做的事情是将不良的工程决策结果投射到他们使用不足的工具上。

您该怎么办？

我的经验是，在罗马时，就像罗马人一样。

不要打架 如果您公司的员工希望将存储过程贴上标签，这是一种不良做法，请让他们使用。但是请注意，这可能是其工程实践中的一个危险信号。

通常在带有大量无能的程序员的组织中将事物标记为不良实践。通过将某些事物列入黑名单，组织试图限制由于自身能力不足而在内部造成的损害。我不拉你

概括是所有失败的源泉。说存储过程（或任何类型的技术）是不好的做法，这是一种概括。概括是无能的解决方案。工程师不能进行公然的概括。他们会根据具体情况进行分析，权衡分析并根据手头的事实执行工程决策和解决方案，以解决问题。

好的工程师不会以这种笼统的方式将事情标记为不良实践。他们着眼于问题，选择合适的工具，进行权衡。换句话说，他们从事工程。

我对如何不使用它们的看法

• 不要在其中进行数据收集（甚至可能进行一些转换）以外的复杂逻辑。可以在其中放置一些数据按摩逻辑，或者将多个查询的结果聚合在一起。就是这样。超出此范围的任何内容都应视为应该驻留在其他地方的业务逻辑。

• 不要将它们用作防御SQL注入的唯一机制。您可以将它们留在这里，以防万一有坏事发生，但是在它们前面应该有一系列防御性逻辑-客户端验证/清理，服务器端验证/清理，可能转换成对您有意义的类型域模型，最后传递给参数化的语句（可以是参数化的SQL语句或参数化的存储过程。）

• 不要使数据库成为唯一包含存储过程的地方。您应该像对待C＃或Java源代码一样对待您的商店proc。也就是说，源代码控制您存储过程的文本定义。人们对存储过程的抱怨不能被源代码控制-废话，他们只是不知道他们在说什么该死的地狱。

我对如何/在何处使用它们的看法

• 您的应用程序需要从多个查询或视图中转置或聚合的数据。您可以将其从应用程序卸载到数据库中。在这里，您必须进行性能分析，因为a）数据库引擎在执行这些操作方面比应用程序服务器更有效，但是 b）（有时）应用程序服务器更易于水平扩展。

• 细粒度的访问控制。您不希望某些笨蛋在数据库中运行笛卡尔联接，但是您不能仅仅禁止人们像这样执行任何SQL语句。一种典型的解决方案是允许在开发和UAT环境中使用任意SQL语句，而在systest和生产环境中禁止使用它们。任何必须使其进入systest或生产环境的语句都会进入存储过程，由开发人员和dbas进行代码审查。

运行不在存储过程中的SQL语句的任何有效需求都将通过不同的用户名/帐户和连接池（对使用情况进行高度监视和劝阻）。

• 在像Oracle这样的系统中，您可以访问LDAP或创建到外部数据库的符号链接（例如，通过vpn在业务伙伴的db上调用存储过程。）执行意大利面条式代码的简便方法，但这对于所有编程范例都是正确的，有时您有特定的业务/环境要求，这是唯一的解决方案。Store proc有助于将这种烦恼单独封装在一个地方，靠近数据，而不必遍历应用服务器。

您是在数据库上作为存储过程还是在应用服务器上运行此程序，取决于工程师（工程师）必须进行的权衡分析。两种选择都必须进行分析，并通过某种类型的分析进行论证。通过简单地指责另一种替代方法是“不好的做法”而走了一条路，这只是一个la脚的工程解决方案。

• 在您根本无法扩展应用服务器的情况下（例如，没有新硬件或云实例的预算），但是数据库后端具有足够的容量（这是很多人都愿意承认的典型情况），移动业务逻辑以存储proc。它不漂亮，可能会导致贫乏的领域模型……但随后又要……权衡分析，这是大多数软件黑客都难以接受的事情。

无论这是否成为永久性解决方案，这都是特定于该特定时刻观察到的约束。

希望能帮助到你。

这样做的理由是，依赖于存储过程层会限制可移植性，并将您与某个数据库绑定在一起。也有增加维护成本的原因。我也想对您提出的这一点发表评论：

（存储过程）保护您免受SQL注入攻击

实际上，这是保护您的参数化查询，您可以在纯文本sql查询中轻松地做到这一点。

我同意存储proc的某些原因不是最佳做法。

• 业务和应用程序逻辑应在代码中而不在数据库中。将逻辑放在数据库中令人担忧。
• 您无法使用其余的应用程序逻辑像常规单元测试项目中那样无缝地测试存储的proc。
• 在编写代码时，我发现存储的proc不利于测试首次编程。
• 在IDE中调试程序时，存储的proc不像应用程序代码那样容易调试。
• SP的版本控制/源代码控制与常规代码

存储过程为您提供代码重用和封装（软件开发的两个支柱），

是的，但是以能够满足其他敏捷设计目标为代价。一方面，它们更难以维护。如果我参与的项目有任何迹象，您最终可能会得到多个不兼容的SP，这些SP基本上完成了相同的工作，而没有任何好处。

保护您免受SQL注入攻击，

不，他们没有。正如我经常听到的那样，我什至无法开始猜测这个想法可能从何而来，这根本不是事实。它可以缓解某些类型的SQL注入攻击，但是如果您首先不使用参数化查询，那将无关紧要。我仍然可以'; DROP TABLE Accounts; -

并且还有助于提高速度（尽管DBA表示，从SQL Server 2008开始，如果常规SQL查询运行了足够的时间，则它们也会被编译）。

通常，在使用准备好的参数化语句时（至少与我使用过的几个DB一起使用），也会对它们进行编译。在您的应用程序开始执行查询时（或特别是当您多次执行相同的准备好的查询时），您认为SP所具有的任何性能优势都完全没有意义。

使用存储过程恕我直言的唯一原因是，当您必须进行一个复杂的，多阶段的查询时，该查询将从多个整理的数据源中提取。SP不应包含低级决策逻辑，并且它们绝不应简单地封装否则为简单的查询。没有好处，只有很多缺点。

听您的DBA。他知道发生了什么事。

这是几年前我在五巨头之一工作时的官方电话。理由是，由于SP绑定到特定的实现（PL / SQL，T / SQL和...），因此它们不必要地限制了技术选择。

经历了一个大型系统从T / SQL到PL / SQL的迁移之后，我可以理解这一论点。我认为这有点让人难过-究竟有多少个地方突然从一个数据库移动到另一个数据库？

我为这三家公司工作的所有公司都使用存储过程来实现SQL Server的应用程序逻辑。相反，我还没有真正看到过事情。但是对我来说，它们真是一团糟。通常没有很好的错误处理工具或带有存储过程的代码重用工具。

假设您有一个存储过程返回了要使用的数据集，那么如何在以后的存储过程中使用它呢？SQL Server上的机制不是很好。EXEC INTO ...仅适用于一层或两层嵌套（我现在忘记了）。或者，您必须预定义工作表并对其进行键控。或者，您需要预先创建一个临时表并让过程填充它。但是，如果两个人在两个他们从未计划同时使用的不同过程中将临时表称为同一件事，该怎么办？在任何普通的编程语言中，您都可以从函数返回数组或指向它们之间共享的对象/全局结构（函数语言除外，在函数语言中您将返回数据结构而不是仅更改全局结构... ）

代码重用如何？如果您开始将通用表达式放入UDF（甚至更糟的子查询）中，则会使代码停顿下来。您无法调用存储过程来为列执行计算（除非您使用游标，将列值一个接一个地传递，然后以某种方式更新表/数据集）。因此，基本上要获得最佳性能，您需要在整个维护工作的噩梦中到处剪切/粘贴通用表达式...使用编程语言，您可以创建一个函数来生成通用SQL，然后在构建时从任何地方调用它SQL字符串。然后，如果您需要调整公式，则可以在一个地方进行更改...

错误处理如何？SQL Server有许多错误会立即停止存储过程的执行，甚至会导致断开连接。自2005年以来，出现了try / catch，但是仍然存在许多无法捕获的错误。同样，错误处理代码上的代码重复也会发生同样的事情，您真的无法像大多数编程语言一样容易地传递异常或将异常冒泡到更高的层次。

也只是速度。数据集上的许多操作都不面向SET。如果您尝试进行面向行的操作，则要么使用游标，要么使用“游标”（当开发人员经常逐行查询每一行并将内容像游标一样存储到@变量中时）。 ..即使这通常比FORWARD_ONLY游标要慢）。在使用SQL Server 2000之前，我已经运行了1个小时，而我杀死了它。我在Perl中重写了该代码，并在20分钟内完成了代码。当比C慢20-80倍的脚本语言在性能上抽走SQL时，您肯定没有业务用SQL编写面向行的操作。

现在，SQL Server确实具有CLR集成，如果您使用CLR存储过程，则很多此类问题都会消失。但是出于安全考虑，许多DBA都不知道如何编写.NET程序或关闭CLR，并坚持使用Transact SQL。 。

通常，最难扩展的是数据库。如果您所有的业务逻辑都在数据库中，那么当数据库变得太慢时，您将遇到问题。如果您有业务层，则可以添加更多缓存和更多业务服务器以提高性能。传统上，另一台安装Windows / Linux并运行.NET / Java的服务器比购买另一台数据库服务器并为更多SQL Server授予许可要便宜得多。但是，SQL Server现在确实提供了更多的群集支持，最初它实际上没有任何支持。因此，如果您确实有很多钱，则可以添加群集，甚至可以做一些日志传送来制作多个只读副本。但是总的来说，这将比仅在高速缓存中写入内容或其他东西花费更多。

还要看一下Transact-SQL工具。字符串操作？我每天都会上Java String Class / Tokenizer / Scanner / Regex类。哈希表/链接列表/等等。我将使用Java Collection框架等。对于.NET也是相同的。C＃和Java比Transact SQL更加进化。 。

此外，存储过程对于处理大型数据集和应用多个查询/条件以将其缩小后再返回到业务层更为有效。如果您必须向客户端应用程序发送一堆庞大的数据集并在客户端上分解数据，那将比仅在服务器上完成所有工作效率低得多。

存储过程也对安全性有好处。您可以削减对基础表的所有访问，仅允许通过存储过程进行访问。使用XML之类的现代技术，您可以具有执行批处理更新的存储过程。然后，通过存储过程控制所有访问，因此只要它们是安全/正确的，数据就可以具有更高的完整性。

由于我们已经在编程语言方面进行了参数化查询，因此SQL注入参数不再真正适用。同样，即使在参数化查询之前，大多数情况下，在大多数情况下也可以使用replace（“'”，“''”）来工作（尽管仍然有一些技巧可以使用字符串末尾来获得所需的内容）。

总的来说，我认为SQL和Transact SQL是查询/更新数据的好语言。但是对于编码任何类型的逻辑，请执行字符串操作（或heck文件操作...。您会对使用xp_cmdshell可以执行的操作感到惊讶。...）请不要。我希望找到一个将来不主要使用存储过程的地方。从代码可维护性的角度来看，这是一场噩梦。如果您要切换平台，也会发生什么（尽管实际上，如果您购买了Oracle / DB2 / Sybase / Sql Server / etc。您也可以通过使用所有可以帮助您的专有扩展来获得所有功能。 ..）。

同样令人惊讶的是，业务逻辑常常是不同的。在理想情况下，您会将所有逻辑放入存储过程中并在应用程序之间共享。但是，逻辑常常会因应用程序而异，并且您的存储过程最终变得过于复杂，人们害怕更改并且不了解其所有含义。使用良好的面向对象语言，您可以编写一个数据访问层，该层具有一些标准接口/钩子，每个应用程序都可以根据自己的需要进行覆盖。

您如何在服务器上对存储过程进行版本控制？

如果您从版本控制将存储过程重新部署到服务器，则会炸毁存储的执行计划。

存储过程不应直接在服务器上进行修改，否则您如何知道当前正在实际运行的是什么？如果不是，则部署工具需要访问权限以将存储过程写入数据库。您必须在每个构建上进行部署（执行计划可能需要有所不同）

尽管存储过程是不可移植的，但一般来说SQL都不是（从未见过的oracle日期处理-uggghhh）。

因此，如果您希望具有可移植性，请构建一个内部数据访问API。您可以像调用函数一样调用此函数，并且可以在内部使用所需的语言内置参数化查询，并且可以对其进行版本控制。

这与我学到的一切都太相反了。

您可能需要更多。[笑]严重的是，存储的处理程序已下降至少10年了。自从n层取代客户端服务器以来，几乎已经有了。仅通过采用Java，C＃，Python等OO语言加速了这种下降。

这并不是说存储过程没有其拥护者和拥护者-但这是一个长期的讨论和辩论。这不是新事物，并且可能还会持续相当长的一段时间。IMO，存储过程的对手显然是赢家。

存储过程为您提供代码重用和封装（软件开发的两个支柱）

非常真实 但是，体面设计的OO层也是如此。

安全性（您可以授予/撤消对单个存储过程的权限）

尽管可以做到，但由于严重的限制，很少有人这样做。数据库级别的安全性不够精细，无法做出上下文感知的决策。由于性能和管理开销，通常也无法建立每个用户的连接-因此，您的应用程序代码中仍需要一定级别的授权。您可以使用基于角色的登录名，但是您将需要为新角色创建它们，维护您作为哪个角色运行，切换连接以执行“系统级”工作，例如登录等。最后，如果您的应用是拥有-与数据库的连接也拥有。

保护您免受SQL注入攻击

只不过是进行参数化查询。无论如何，您都需要这样做。

并且还有助于提高速度（尽管DBA表示，从SQL Server 2008开始，如果常规SQL查询运行了足够的时间，则它们也会被编译）。

我认为这始于MSSQL 7或2000。关于存储proc和内联SQL性能的争论，度量和错误信息很多-我将其全部归类于YAGNI。并且，如果您确实需要它，请进行测试。

我们正在使用敏捷软件开发方法开发复杂的应用程序。任何人都可以考虑为什么不想使用存储的proc的充分理由吗？

我想不出您想要的许多原因。Java / C＃/任何第3 GL语言在封装，重用和可扩展性等方面都比T-SQL强大得多。考虑到ORM不错，大多数都是免费的。

另外，考虑到“根据需要分配，但不能更多”的建议，我认为这些天的举证责任在SP倡导者身上。使存储过程繁重的一个常见原因是T-SQL比OO更容易，并且商店比T.SQL具有更好的T-SQL开发人员。或者，DBA停在数据库层，而存储的proc是dev和DBA之间的接口。或者，您正在运送半定制产品，并且存储的过程可以由用户定制。缺乏类似的考虑，我认为这些天任何敏捷软件项目的默认设置都将是ORM。

考虑到以上所有情况，我想再添加一个。SP的选择也可能取决于人们的选择。

当人们在SP中放置非常复杂的逻辑时，我个人感到沮丧，并且我相信此类SP的维护和调试非常复杂。甚至在很多情况下，开发人员本人都面临着在后台代码（例如语言部分）中进行调试比在SP中容易得多的问题。

SP仅应用于简单操作。那是我的选择。

我想同时介绍存储过程的一些利弊。我们在LedgerSMB中广泛使用它们，并且我们的规则是，通过一些非常具体的扩展，“如果是查询，则将其存储为proc。”

我们这样做的原因是为了促进跨语言查询的重用。老实说，没有更好的方法。

最后，问题总是在细节上。如果使用得当，存储过程会使事情变得容易得多，而如果使用不当，它们会使事情变得更加困难。

因此，在不利方面。

1. 正如传统上使用的那样，存储过程很脆弱。单独使用它们可以为您添加代码错误的可能性，这些错误是在您除了调用语法发生更改之外的其他所有意外地方。单独使用会有点问题。层之间的内聚性太大，这会引起问题。

2. 是的，如果执行任何动态SQL，则可以进行过程内SQL注入。在这个领域过分自信是一件坏事，因此需要在该领域的安全方面拥有丰富的经验。

3. 由于上面的原因1，对存储过程的接口更改有些问题，但是如果涉及大量的客户端应用程序，这可能会成为一个巨大的噩梦。

以上是很难否认的。他们发生了。支持SP和反对SP的每个人都可能有关于这些的恐怖故事。这些问题并非无法解决，但是如果您不关注它们，就无法解决（在LedgerSMB中，我们使用服务定位器在运行时动态构建SP调用，从而完全避免了上述问题。）只能对其他数据库执行类似的操作）。

积极向上。假设您可以解决上述问题，您将获得：

1. 设置操作中提高清晰度的可能性。如果查询很大或非常灵活，则尤其如此。这也导致增强的可测试性。

2. 如果我已经在该领域工作过服务定位器，那么我发现存储过程可以加快开发速度，因为它们使应用程序开发人员摆脱了数据库问题，反之亦然。在做正确的事情上有一些困难，但是做起来并不难。

3. 查询重用。

哦，您在SP中几乎应该做不到的几件事：

1. 非交易逻辑。您发送了一封电子邮件，说明订单已经发货，但是交易已回滚...或者现在您正在等待继续使电子邮件服务器联机....更糟糕的是，您回滚交易只是因为您无法到达电子邮件服务器...

2. 许多小查询松散地串在一起，并散布着程序逻辑。

你为谁工作？

答案可能取决于您雇用的人，咨询公司或公司本身。对于公司而言，最好的选择通常对咨询公司或其他软件供应商来说不是最好的选择。例如，一家精明的公司希望拥有比竞争对手持久的优势。相比之下，软件供应商希望能够以最低的成本为特定行业的所有企业提供相同的解决方案。如果他们在此方面取得成功，那么客户将没有净竞争优势。

在这种特殊情况下，应用程序来来往往，但企业数据库却永远存在。RDBMS要做的主要事情之一是防止垃圾数据进入数据库。这可能涉及存储过程。如果逻辑是好的逻辑并且极不可能每年更改，那么无论使用何种应用程序编写使用该数据库的逻辑，为什么都不应将其保留在数据库中，并使其内部保持一致？几年后，有人会问他们想问数据库的问题，如果阻止垃圾邮件进入数据库，这将是可以回答的。

因此，这可能与您的DBA在咨询公司工作有关。他们使代码的可移植性越强，它们在客户端之间重用代码的可能性就越大。他们可以在应用程序中使用的逻辑越多，公司与供应商的联系就越多。如果他们在此过程中留下了很大的混乱，他们将获得报酬以清理它，或者再也看不到混乱了。无论哪种方式对他们来说都是胜利。

有关围栏两侧的更多讨论，请阅读恐怖编码上的讨论。FWIW我倾向于那些主张SP的人。

切换数据库品牌并利用相同的存储过程非常困难。

您的团队没有DBA，没有其他人希望与sql有任何关系。

这无非是程序员与DBA撒尿大赛。

IMO这取决于。存储过程虽然占了上风，但不是最佳实践，也不是不惜一切代价避免的事情。精明的开发人员知道如何正确评估给定情况并确定存储过程是否是答案。就个人而言，我喜欢使用某种ORM（甚至是诸如原始的Linq到Sql这样的基本ORM），而不是使用存储过程，除了可能用于预定义的报告或类似的报告外，但这确实是个案的基础。

使用不同的编程语言将业务逻辑划分到不同的层之间，始终是问题的根源。当您必须在世界之间切换时，追踪错误或实施更改会变得更加困难。

就是说，我知道通过将所有业务逻辑放入数据库中存在的PL / SQL包中的公司表现相当不错。这些不是很大的应用程序，但也不是一件容易的事。例如20K-100K LOC。（PL / SQL比T-SQL更适合于这种系统，因此，如果您只了解T-SQL，您可能现在就摇摇头……）

这是尚未提及的另一点：

代码生成工具和逆向工程工具无法真正很好地应对存储过程。该工具通常无法分辨proc的作用。proc是否返回结果集？几个结果集？是否从几个表和临时表中获取结果集？proc是封装的update语句，不返回任何内容吗？它是否返回结果集，返回值和一些“控制台输出”？

因此，如果您想使用一种工具来自动创建数据传输对象DTO和DAO层（例如liferay的“服务构建器”），您将不容易做到。

而且，当数据源是SP时，像Hibernate这样的ORM不能真正正常工作。数据访问最多是只读的。

单独编程，我无法抗拒编写存储过程。

我主要使用MySQL。我以前没有像PostGreSQL那样使用过面向对象的数据库，但是我在MySQL中使用SP所能做的就是稍微抽象了表结构。SP使我能够设计这些原始动作，即使它们下面的数据库发生了变化，其输入和输出也不会改变。

因此，我有一个名为的过程logIn。登录时，您始终只通过username和password。传回的结果是整数userId。

如果logIn是一个存储过程，现在我可以添加在登录时出现这种情况，同时作为初始日志中做额外的工作。我发现与嵌入式逻辑一系列SQL语句在存储过程中更容易编写比（主叫环境FETCH）->（获取结果）->（调用环境FETCH）系列，这是在编写逻辑服务器端时必须要做的。

我还要指出，存储过程确实在服务器上使用cpu时间。不是很多，但是有些。在工作过程中完成的某些工作可以在应用程序中完成。扩展应用层比扩展数据层更容易。

我同意Mark的观点，即社区确实已经离开存储过程已有相当一段时间了。尽管原始发布者提出的许多观点一次都有效的原因使我们想使用SP，但是已经有一段时间了，而且正如另一位发布者所说，环境已经改变。例如，我记得一个关于“在一天之内”使用SP的论点是获得的性能提升，因为它们的执行计划是“预编译”的，而每次执行时都必须“重新编译”来自我们代码的动态SQL。随着主要数据库的更改，改进，改编等，情况不再如此。

也就是说，我们在当前项目中使用的是SP。原因仅仅是因为我们在仍支持旧版应用程序的现有数据库之上构建新应用程序。因此，在我们关闭旧版应用程序之前，很难更改架构。我们做出了一个明智的决定，即根据应用程序所需的行为和规则来设计我们的新应用程序，并使用SP以我们希望的方式临时连接数据库，并使SP适应现有的SQL。 。这可以说是先前发布者的观点，即SP使得在数据库级别进行更改变得更容易，而无需更改应用程序代码。使用SP作为Adapter模式的实现对我当然是有意义的（尤其是考虑到当前的项目），

首先，我们打算在更新架构时删除SP。但是，与公司发展中的所有其他事情一样，我们将看看这种情况是否会发生！[咧嘴]

我只是想简要概述如何建议使用存储过程。我认为这根本不是一个坏习惯，就像其他人所说的那样，应该在适当的情况下使用它们。

我看到一些问题，在这些问题中，为不同应用程序编写程序的功能可能会变得混乱，并使应用程序的业务逻辑分离，并导致数据库变得更加混乱和严格。

因此，我将在特定于数据库的面向关系数据的任务中使用存储过程。换句话说，如果存在用于数据库操作的逻辑与任何应用程序的数据相一致，则可以使用存储过程来保持数据的一致存储（有意义）。我认为很好的例子是：一致的日志记录，一致的维护，使用敏感信息等。

我认为，其他任务将按照数据库的强大数据模型来操纵数据以适合应用程序的需求，然后将它们存储在包含业务逻辑的另一层中。简而言之，为确保一致性而使用的特定于数据库的数据操作可以使用存储过程，其中一致性超出了数据库完整性模式模型的范围。

“对我而言”存储过程适用于OLAP“只读”操作，很少使用。

对于业务规则，OLTP读/写操作我更喜欢Java应用程序服务器。为了简化编码并尽可能减轻主数据库服务器的CPU和内存负载。在此设置中，应用程序服务器中的所有代码都不难检查或记录，并且具有可伸缩性。

对我来说重要的是，与在存储层中进行调试相比，在业务层中进行调试更容易。

除了不必要地分发业务逻辑，并将您与特定的数据库供应商联系在一起之外，我还坚信要按预期使用技术。数据库就是关系数据存储。用它来存储数据，别无其他。

明智地选择您的工具，从长远来看，您将为自己省下很多麻烦。