将SQL保存在c#源代码或Stored Procs中有哪些优点/缺点?我一直在和一个朋友讨论这个问题,我们正在做一个开源项目(c# ASP。网论坛)。目前,大多数数据库访问都是通过在c#中构建内联SQL并调用SQL Server DB来完成的。所以我在试着确定,对于这个特定的项目,哪个是最好的。
到目前为止,我有:
in Code的优点:
更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植
存储Procs的优点:
性能 安全
将SQL保存在c#源代码或Stored Procs中有哪些优点/缺点?我一直在和一个朋友讨论这个问题,我们正在做一个开源项目(c# ASP。网论坛)。目前,大多数数据库访问都是通过在c#中构建内联SQL并调用SQL Server DB来完成的。所以我在试着确定,对于这个特定的项目,哪个是最好的。
到目前为止,我有:
in Code的优点:
更容易维护-不需要运行SQL脚本来更新查询 更容易移植到另一个DB -没有pros到移植
存储Procs的优点:
性能 安全
当前回答
存储过程的优先级,因为: 在系统运行时修复一些生产中与数据相关的问题(这对我来说是第一个) - DB和程序之间清晰的契约定义(清晰的关注点分离) -更好的可移植性到不同的DB供应商(如果写得好,代码更改通常只在SP端)。 -更好地进行性能调优
缺点:WHERE子句在使用条件上有很大的变化,需要高性能。
其他回答
SQL存储过程不会提高查询的性能
这样想
你有4个web服务器和一堆使用相同SQL代码的windows应用程序 现在您意识到SQl代码有一个小问题 所以你宁愿...... 在一个地方改变过程 或 将代码推送到所有的网络服务器上,重新安装所有Windows盒子上的所有桌面应用程序(单击一次可能会有帮助)
我更喜欢存储过程
它也更容易做一个过程的性能测试,把它放在查询分析器 设置io/time on统计信息 设置showplan_text,瞧
不需要运行分析器来查看到底调用了什么
这只是我的小意思
我想再投一票赞成使用存储过程(尽管在维护和版本控制时它们会带来麻烦)作为一种限制对底层表的直接访问以获得更好的安全性的方法。
我非常支持代码而不是SPROC。第一个原因是保持代码紧密耦合,第二个原因是源代码控制的便利性,而不需要大量自定义实用程序。
在我们的DAL中,如果我们有非常复杂的SQL语句,我们通常将它们作为资源文件,并在需要时更新它们(这也可以是一个单独的程序集,并在每个db中交换,等等……)
这使得我们的代码和sql调用存储在同一个版本控制中,而不会“忘记”运行一些外部应用程序进行更新。
在安全性方面,存储过程要安全得多。一些人认为,无论如何,所有的访问都将通过应用程序进行。许多人忘记了一件事,即大多数安全漏洞来自公司内部。想想有多少开发人员知道应用程序的“隐藏”用户名和密码?
此外,正如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差)。