在 C# 中存储查询或在 Postgres 中使用存储函数？答案

【问题标题】：Storing Queries in C# or use Stored Functions in Postgres?在 C# 中存储查询或在 Postgres 中使用存储函数？
【发布时间】：2010-10-02 09:32:18
【问题描述】：

我应该将原始 SQL 查询存储在我的 c# 代码中，还是应该将它们委托给 Postgres 后端中的存储函数？

如果我应该将它们存储在代码中，因为它们可能会变得很长，那么存储它们的最佳方式是什么（即，作为单独的静态类中的常量）？

使用存储函数对应用程序的可部署性/可更新性有任何影响吗？

谢谢

【问题讨论】：

标签： c# sql postgresql

【解决方案1】：

通常，我们通过存储过程而不是直接的 SQL 语句来进行所有数据库交互；这为调整架构更改和性能问题提供了很大的灵活性，而无需为所有目标重新构建或重新部署二进制映像或配置文件。

【讨论】：

【解决方案2】：

我非常喜欢将 SQL 存储在作为资源嵌入到程序集中的文本文件中（当我绝对必须拥有大量它们时；我通常是 ORM 人）。

当然，如何格式化该文本文件完全取决于您。您可以使用双换行符分隔：

UpdateCustomer:
UPDATE CUSTOMER SET NAME=@Name WHERE ID=@ID

FindCustomer:
SELECT NAME, ADDRESS FROM CUSTOMER
WHERE ID=@Id

etc

然后有一个类将其加载到类型初始化器中的Dictionary<string,string> 中并不难，甚至是Dictionary<string,SqlStatementHelper>，其中后者是一个类，以便轻松准备具有适当值的语句。不过，您可以使用任何其他您想要的格式，包括 XML - 尽管如果您不需要除了名称/sql 对之外的任何其他格式，那可能就有点过头了。

这样做的缺点是 SQL 和使用它的代码之间的脱节 - 如果不查看文本文件，您无法立即知道参数是什么。另一方面（我只是想一想），您可能可以使用具有强类型参数的方法从 SQL（和一些元数据）自动生成一个类。

存储过程的好坏参半是它们存在于数据库中，而不是您的代码中。这样做的好处是您更有可能使它们与 DDL 更改保持同步。缺点是它们比本地定义的查询更努力地改变（IME，无论如何）。（显然还有很多其他优点和缺点，但我将自己限制在方便的一面。）

至于维护 - 好吧，我想你有可能只对表和存储过程进行“仅数据库”更新，而无需任何客户知道 - 在这种情况下，存储过程会更好移动。以我的经验（当然对于只有几个应用程序访问数据库的自定义解决方案，因此兼容性不是问题）代码更改几乎无处不在，但数据库更改较少 - 在这一点将查询存储在应用程序中意味着您在更新时不太可能需要更改数据库。这有什么意义吗？我还没喝咖啡……

【讨论】：

【解决方案3】：

不管怎样！但逐案，

代码级别的 SQL 作为常量，

在编译时评估值，这可以优化性能。
它是安全的，在编译或部署代码后无法修改。
有些人通过将所有 SQL 文本通过线路发送到 sql 服务器来降低性能。
如果 SQL 是动态创建的，则会在安全性方面存在一些缺陷。

SQL 函数级别的 SQL

更安全，因为参数是输入。
更容易维护数据库模式。例如如果一个函数正在引用它，则不能删除表。
只需发送即可获得更好的性能通过函数名和参数到 SQL 服务器。
更容易在函数级别应用修补程序，因为它没有被编译。人们可以查看和修改您的代码，因为它以纯文本形式公开。
维护应用程序和 sql 函数之间的版本的一些缺点。

【讨论】：

【解决方案4】：

从正常的可部署性/可更新性考虑，将 SQL 查询存储在代码中会限制您的选择，因为与 SQL 存储过程的通常修改/修补程序相比，源代码在部署时不太可能被重新编译。

当然，这也取决于您的“更新”有多大。如果业务逻辑发生重大变化或需要切换数据库，这点将是心情

【讨论】：

【解决方案5】：

我认为使用存储过程会更好，因为它可以提供性能。如果可能的话。

我的意思是 - 查询和源代码、局部变量等足够“独立” - 它不需要太多“准备”，您只需将一些变量作为参数发送到存储过程。

【讨论】：