在C＃中存储查询或在Postgres中使用存储函数？

Question

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

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

使用存储的函数是否会对应用程序的可部署性/可更新性产生影响？

由于

Answer 1

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

Answer 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，无论如何）。 （显然还有很多其他优点和缺点，但我在这里限制自己的方便性。）

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

Answer 3

无论哪种方式！但视具体情况而定，

代码级别的SQL为常量，

• 在编译时评估值，这可以优化性能。
• 安全，编译或部署代码后无法修改。
• 有些人通过线路将所有SQL文本发送到sql server来回退性能。
• 如果动态创建SQL，安全性会有一些缺陷。

SQL函数级别的SQL

• 因为参数更安全 键入。
• 更容易针对数据库架构进行维护。例如如果一个函数引用它，则表不能删除。
• 只需发送即可获得更好的性能 通过函数名称和参数 到SQL服务器。
• 更容易在功能级别应用修补程序，因为它未编译。 人们可以看到＆amp;修改你的代码，因为它以纯文本形式公开。
• 在应用程序和sql函数之间维护版本的一些缺点。

Answer 4

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

当然，这也取决于你的“更新”有多大。如果业务逻辑发生重大变化或需要数据库切换，这一点就会很有气氛

Answer 5

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

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