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

到目前为止,我有:

in Code的优点:

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

存储Procs的优点:

性能 安全


当前回答

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

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

其他回答

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

存储过程的更多优点:

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

很明显,使用存储过程比在代码中构造SQL有几个优点。

代码实现和SQL变得彼此独立。 代码更容易阅读。 写一次用多次。 修改一次 不需要向程序员提供关于数据库的内部细节。等等,等等。

你的编程语言和应用程序框架可能是:

高级的,特别是与SQL相比 易于通过自动化流程进行版本和部署,特别是与SQL相比

如果这两个条件是两个,则跳过存储过程。

存储过程更易于维护,因为:

你不需要重新编译你的c#应用每当你想改变一些SQL 您最终会重用SQL代码。

当您试图构建可维护的应用程序时,代码重复是最糟糕的事情!

当您发现需要在多个地方纠正的逻辑错误时会发生什么?您更容易忘记更改复制和粘贴代码的最后一个位置。

在我看来,性能和安全性的提高是一个额外的加分项。您仍然可以编写不安全/低效的SQL存储过程。

更容易移植到另一个DB -没有pros到移植

在另一个DB中创建所有存储过程并不难。事实上,它比导出表更容易,因为不需要担心主键/外键。

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

此外,正如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差)。