将SQL保存在c#源代码或Stored Procs中有哪些优点/缺点?我一直在和一个朋友讨论这个问题,我们正在做一个开源项目(c# ASP。网论坛)。目前,大多数数据库访问都是通过在c#中构建内联SQL并调用SQL Server DB来完成的。所以我在试着确定,对于这个特定的项目,哪个是最好的。

到目前为止,我有:

in Code的优点:

更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植

存储Procs的优点:

性能 安全


当前回答

存储过程的优点 1).提高安全性,因为存储过程中的SQL本质上是静态的(大多数)。这将防止SQL注入。 2)。可重用性。如果需要为多个应用程序/组件返回相同的数据,这可能是一个更好的选择,而不是重复SQL语句。 3).减少客户端与数据库服务器之间的调用。

我不确定其他数据库,但您可以在大型机上的db2中使用主机语言创建存储过程,这使得它们非常强大。

其他回答

Definitely easier to maintain if you put it in a stored procedure. If there's difficult logic involved that will potentially change in the future it is definitely a good idea to put it in the database when you have multiple clients connecting. For example I'm working on an application right now that has an end user web interface and an administrative desktop application, both of which share a database (obviously) and I'm trying to keep as much logic on the database as possible. This is a perfect example of the DRY principle.

在某些情况下,在代码中动态创建的sql可能比存储的proc具有更好的性能。如果您已经创建了一个存储的proc(例如sp_customersearch),它必须非常灵活,因此具有许多参数,非常复杂,那么您可能可以在运行时在代码中生成一个更简单的sql语句。

有人可能会说,这只是将一些处理从SQL转移到web服务器,但总的来说,这是一件好事。

这种技术的另一个优点是,如果你在SQL分析器中查找,你可以看到你生成的查询,调试它比看到一个存储的带有20个参数的proc调用要容易得多。

@Terrapin - scprocs同样容易受到注射攻击。正如我所说:

总是参数化所有的查询-永远不要内联用户输入的东西,你会没事的。

这适用于sprocs和动态Sql。

我不确定不重新编译你的应用程序是一个优势。我的意思是,在重新上线之前,您已经针对该代码(应用程序和DB)运行了单元测试。


@Guy -是的,你是对的,sproc确实让你控制应用程序用户,这样他们就只能执行sproc,而不是底层的操作。

我的问题是:如果所有人都通过你的应用程序访问它,使用连接和用户只有有限的更新/插入权限等,这个额外的级别是否增加了安全性或额外的管理?

我的观点是后者。如果他们已经破坏了您的应用程序,可以重新编写它,那么他们还有很多其他的攻击可以使用。

如果动态内联代码,Sql注入仍然可以针对这些spprocs执行,所以黄金法则仍然适用,所有用户输入必须始终参数化。

存储过程。

如果出现错误或者逻辑稍有变化,您不必重新编译项目。此外,它允许从不同的来源访问,而不仅仅是在项目中编写查询的一个地方。

我不认为维护存储过程更难,你不应该直接在数据库中编写它们,而应该先在单独的文件中编写,然后你可以在任何你需要设置的DB上运行它们。

存储过程比代码更容易在数据库和源代码控制系统之间失去同步。应用程序代码也可以,但当您进行持续集成时,这种可能性较小。

数据库就是这样,人们不可避免地对生产数据库进行更改,只是为了暂时摆脱困境。然后忘记在环境和源代码控制系统之间同步它。生产数据库迟早会成为事实上的记录,而不是源代码控制系统——您将陷入无法删除任何scprocs的情况,因为您不知道它是否正在被使用。

一个好的过程应该只允许通过适当的渠道对产品进行更改,这样您就能够从源代码控制系统(无数据)从头开始重新构建数据库。但我只是说,因为它可以完成,也确实完成了——在最激烈的时刻,在大喊大叫的客户的电话之间,在紧盯着你的经理的电话之间,等等,对生产数据库进行了更改。

使用存储过程运行特别查询很尴尬——使用动态sql(或ORM)更容易,这可能是我自己使用存储过程的最大缺点。

另一方面,存储过程在你做出更改但不需要重新部署应用程序代码的情况下很好。它还允许您在通过网络发送数据之前对数据进行塑形,而代码中的sql可能必须进行多次调用来检索而不是塑形(尽管现在有方法可以在一次“调用”中运行多个sql语句并返回多个结果集,如ADO.NET中的MARS),这可能会导致更多的数据通过网络传输。

不过,我不相信任何关于性能和安全性的争论。两者都有可能是好的,也有可能是坏的,而且同样可控。