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

到目前为止,我有:

in Code的优点:

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

存储Procs的优点:

性能 安全


当前回答

没有人提到单元测试!

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

其他回答

我不是存储过程的狂热爱好者,但我在一种情况下使用它们:

当查询相当大时,最好将其作为存储过程存储在数据库中,而不是从代码中发送。这样,就不会从应用服务器向数据库发送大量字符串字符,而只发送“EXEC SPNAME”命令。

当数据库服务器和web服务器不在同一个网络上(例如,internet通信)时,这是多余的。即使事实并非如此,太大的压力也意味着大量的带宽浪费。

但是,伙计,管理起来太糟糕了。我尽量避开他们。

存储过程的性能优势通常可以忽略不计。

存储过程的更多优点:

防止反向工程(当然,如果使用加密创建的话) 更好地集中数据库访问 能够透明地更改数据模型(无需部署新客户端);当多个程序访问相同的数据模型时尤其方便

我站在代码这一边。我们构建了所有应用程序(包括web和客户端)使用的数据访问层,所以从这个角度来看这是DRY。它简化了数据库部署,因为我们只需要确保表模式是正确的。它简化了代码维护,因为我们不需要查看源代码和数据库。

在与数据模型的紧密耦合方面,我没有遇到太多问题,因为我看不出哪里有可能真正打破这种耦合。应用程序及其数据在本质上是耦合的。

在安全性方面,存储过程要安全得多。一些人认为,无论如何,所有的访问都将通过应用程序进行。许多人忘记了一件事,即大多数安全漏洞来自公司内部。想想有多少开发人员知道应用程序的“隐藏”用户名和密码?

此外,正如MatthieuF所指出的,由于应用程序(无论是在桌面服务器还是web服务器上)和数据库服务器之间的往返次数减少,性能可以得到很大的提高。

In my experience the abstraction of the data model through stored procedures also vastly improves maintainability. As someone who has had to maintain many databases in the past, it's such a relief when confronted with a required model change to be able to simply change a stored procedure or two and have the change be completely transparent to ALL outside applications. Many times your application isn't the only one pointed at a database - there are other applications, reporting solutions, etc. so tracking down all of those affected points can be a hassle with open access to the tables.

我还将在加分栏中加上检查,以使SQL编程掌握在专门的人员手中,并使sp更容易隔离和测试/优化代码。

我看到的一个缺点是,许多语言不允许传递表参数,因此传递未知的数据值可能很烦人,一些语言仍然无法处理从单个存储过程中检索多个结果集(尽管后者在这方面并不使sp比内联SQL差)。

程序员希望代码在他们的应用程序中,DBA希望它在数据库中。

如果你两者都有,你可以通过使用存储过程在两者之间分配工作,程序员不必担心所有这些表如何连接在一起等(对不起,我知道你想控制一切。)

我们有一个第三方应用程序,它允许在数据库中的视图或存储过程上创建自定义报告。如果我把代码中的所有逻辑都放在另一个应用程序中,就不能重用它。如果你使用数据库编写所有的应用程序,这不是问题。