将存储过程迁移到应用程序中答案

【问题标题】：Migrating Stored Procedures into application将存储过程迁移到应用程序中
【发布时间】：2011-03-19 08:42:16
【问题描述】：

我现在面临的存储过程的所有这些缺点（数据库可移植性等）。我们要将我们的 VB.Net/ASP/SQL Server 应用程序迁移到 Mono/Postgresql 之类的应用程序并完全国际化。

我们面临的众多问题之一是我们有 800-900 个存储过程。我们正在考虑将这些 SP 中的逻辑转移到应用程序代码中。我已经四处寻找人们是如何做到这一点或如何做到这一点的，但是我发现的很少。大多数关于存储过程的信息都是关于它们应该包含什么等等。所以我得出的结论是，解决这个问题的最佳方法是将 SQL 检索/更新类型查询保留为存储过程，并使用业务逻辑移动这些查询进入应用程序。

所以我的问题是，做这样的事情最好的方法是什么（可能没有最好的方法，但有一些关于从哪里开始的建议会很好）？

谢谢利亚姆

【问题讨论】：

标签： sql-server vb.net stored-procedures

【解决方案1】：

由于您的存储过程为您的数据库提供了一个接口，您现在需要确保对存储过程的所有调用都转到相同的客户端代码。如果您当前从应用程序中的多个位置，甚至多个应用程序（可能是多模式）调用 SP，它们都需要通过公共代码。我将首先确保每个 SP 仅从客户端库中的一个位置调用。然后，存储过程中的所有逻辑都将被该方法调用封装。如果您的存储过程使用事务来确保复杂操作的完整性，那么现在需要在应用程序端库中启动和提交这些事务。

重构最终是必要的，即使您无法移植所有 SP，也有好处。

【讨论】：

【解决方案2】：

在将 ASP.NET+ SQL Server 应用程序迁移到 Postgres 数据库时，我也遇到了同样的情况。与其将 SP 迁移到您的应用程序代码，不如将它们转换为等效的 pl/pgsql 函数会容易得多。您只需要更改 ADO.NET 提供程序，并且不需要对应用程序代码进行任何更改。有很多 postgres (npgsql) 提供程序将 SP 和 postgres 功能视为等效。

【讨论】：

您好 Avinash，感谢您的回复。实际上，我已经将所有存储过程转换为 Postgres 函数。我之所以认为我们应该将存储的过程合并到应用程序中的主要原因是因为我们很可能会为我们将提供我们的应用程序的不同语言拥有多个数据库。因此更容易管理拥有数据库只存储数据。