将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的优点:
性能 安全
当前回答
存储过程更易于维护,因为:
你不需要重新编译你的c#应用每当你想改变一些SQL 您最终会重用SQL代码。
当您试图构建可维护的应用程序时,代码重复是最糟糕的事情!
当您发现需要在多个地方纠正的逻辑错误时会发生什么?您更容易忘记更改复制和粘贴代码的最后一个位置。
在我看来,性能和安全性的提高是一个额外的加分项。您仍然可以编写不安全/低效的SQL存储过程。
更容易移植到另一个DB -没有pros到移植
在另一个DB中创建所有存储过程并不难。事实上,它比导出表更容易,因为不需要担心主键/外键。
其他回答
存储过程更易于维护,因为:
你不需要重新编译你的c#应用每当你想改变一些SQL 您最终会重用SQL代码。
当您试图构建可维护的应用程序时,代码重复是最糟糕的事情!
当您发现需要在多个地方纠正的逻辑错误时会发生什么?您更容易忘记更改复制和粘贴代码的最后一个位置。
在我看来,性能和安全性的提高是一个额外的加分项。您仍然可以编写不安全/低效的SQL存储过程。
更容易移植到另一个DB -没有pros到移植
在另一个DB中创建所有存储过程并不难。事实上,它比导出表更容易,因为不需要担心主键/外键。
存储过程的优点:
更容易检查代码。
耦合更少,因此更容易测试。
更容易调谐。
从网络流量的角度来看,性能通常更好——如果您有一个游标或类似的东西,那么就不会多次访问数据库
您可以更容易地保护对数据的访问,删除对表的直接访问,通过procs加强安全性——这也允许您相对快速地找到更新表的任何代码。
如果涉及到其他服务(如Reporting服务),您可能会发现将所有逻辑存储在存储过程中,而不是存储在代码中,并且必须复制它会更容易
缺点:
对开发人员来说更难管理的是:脚本的版本控制:每个人都有自己的数据库吗?版本控制系统是否与数据库和IDE集成在一起?
存储过程的性能优势通常可以忽略不计。
存储过程的更多优点:
防止反向工程(当然,如果使用加密创建的话) 更好地集中数据库访问 能够透明地更改数据模型(无需部署新客户端);当多个程序访问相同的数据模型时尤其方便
我不是存储过程的狂热爱好者,但我在一种情况下使用它们:
当查询相当大时,最好将其作为存储过程存储在数据库中,而不是从代码中发送。这样,就不会从应用服务器向数据库发送大量字符串字符,而只发送“EXEC SPNAME”命令。
当数据库服务器和web服务器不在同一个网络上(例如,internet通信)时,这是多余的。即使事实并非如此,太大的压力也意味着大量的带宽浪费。
但是,伙计,管理起来太糟糕了。我尽量避开他们。
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。
因此,请坚持使用仅抽象了关系细节的存储过程,而不是那些包含业务逻辑的存储过程。