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

到目前为止,我有:

in Code的优点:

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

存储Procs的优点:

性能 安全


当前回答

@Keith

安全?为什么scprocs会更安全?

正如Komradekatz所建议的,您可以禁止访问表(对于连接到DB的用户名/密码组合),而只允许SP访问。这样,如果有人获得了数据库的用户名和密码,他们可以执行SP,但不能访问表或数据库的任何其他部分。

(当然,执行scproc可以给他们所有他们需要的数据,但这将取决于可用的scproc。给他们访问表的权限,他们就能访问所有东西。)

其他回答

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

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

这适用于sprocs和动态Sql。

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


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

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

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

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

我参加的Microsoft TechEd安全会议的建议之一是,通过存储过程进行所有调用,并拒绝直接访问表。这种方法被宣传为提供额外的安全性。我不确定仅仅为了安全性是否值得这样做,但如果您已经在使用存储过程,那么这样做也无妨。

没有人提到单元测试!

如果你有一个saveOrder方法,你可以在里面调用几个方法,并为每个方法创建一个单元测试,但如果你只调用一个存储过程,就没有办法做到这一点。

在我工作的地方,sproc的最大优势是我们有更少的代码移植到VB。NET(来自VB6)。而且它的代码更少,因为我们对所有的查询都使用了spprocs。

当我们需要更新查询而不是更新VB代码,重新编译并在所有计算机上重新安装它时,它也有很大的帮助。

Something that I haven't seen mentioned thus far: the people who know the database best aren't always the people that write the application code. Stored procedures give the database folks a way to interface with programmers that don't really want to learn that much about SQL. Large--and especially legacy--databases aren't the easiest things to completely understand, so programmers might just prefer a simple interface that gives them what they need: let the DBAs figure out how to join the 17 tables to make that happen.

话虽如此,用于编写存储过程的语言(PL/SQL就是一个臭名昭著的例子)是相当残酷的。它们通常不提供您在当今流行的命令式语言、OOP或函数式语言中看到的任何细节。认为COBOL。

因此,请坚持使用仅抽象了关系细节的存储过程,而不是那些包含业务逻辑的存储过程。