假设您无论出于何种原因无法使用LINQ,将查询放在存储过程中是一种更好的做法,还是对数据库执行即席查询(例如,为了参数而使用SQL Server)这是一种很好的做法？
根据我编写WinForms客户端/服务器应用程序的经验,这些是我得出的简单结论:
使用存储过程:
对于任何复杂的数据工作.如果您要做一些真正需要游标或临时表的事情,那么在SQL Server中执行它通常是最快的.
当您需要锁定对数据的访问时.如果您不向用户(或角色或其他)提供表访问权限,则可以确保与数据交互的唯一方法是通过您创建的SP.
使用即席查询:
对于CRUD,当您不需要限制数据访问时(或以其他方式这样做).
对于简单的搜索.为一堆搜索标准创建SP是一件痛苦的事情并且难以维护.如果您可以生成相当快速的搜索查询,请使用它.
在我的大多数应用程序中,我都使用了SP和ad-hoc sql,虽然我发现我使用的SP越来越少,因为它们最终成为像C#一样的代码,只是更难以进行版本控制,测试和维护.我建议使用ad-hoc sql,除非你能找到一个特定的理由不这样做.
我不能说除SQL Server以外的任何其他内容,但除非你在6.5或更早版本,否则性能参数在那里并不显着.SQL Server已经缓存了大约十年的临时执行计划.
我认为这是必须维护数据库的人和开发用户界面的人之间的基本冲突.
作为数据人,我不会考虑使用通过adhoc查询访问的数据库,因为它们很难有效地调整或管理.我如何知道对架构的更改会产生什么影响？此外,出于安全原因,我认为不应该授予用户直接访问数据库表的权利(我不仅仅意味着SQL注入攻击,而且因为它是一个基本的内部控制,不允许直接权限并要求所有用户只使用为应用程序设计的过程.这是为了防止可能的欺诈.任何允许直接插入,更新或删除表权限的金融系统都存在欺诈的巨大风险.这是一件坏事.).
数据库不是面向对象的,从面向对象的角度来看似乎很好的代码从数据库的角度来看可能非常糟糕.
我们的开发人员告诉我们他们很高兴我们所有的数据库访问都是通过procs,因为它可以更快地修复以数据为中心的bug,然后在生产环境中运行proc而不是创建代码的新分支并重新编译和重新加载到生产.我们要求所有的proc都处于颠覆状态,所以源控制根本不是问题.如果它不在Subversion中,它将定期被dbas删除,因此使用Source Control没有阻力.
存储过程表示封装对数据库采取的操作的软件合同.可以更改过程中的代码,甚至数据库本身的模式,而不会影响已编译的已部署代码,只是因此过程的输入和输出保持不变.
通过在应用程序中嵌入查询,您可以将自己与数据模型紧密结合.
出于同样的原因,简单地创建仅针对数据库中每个表的CRUD查询的存储过程也是不好的做法,因为这仍然是紧密耦合.相反,程序应该是庞大的粗粒度操作.
从安全角度来看,最好从应用程序中禁用db_datareader和db_datawriter,并且只允许访问存储过程.
存储过程绝对是可行的方法......它们是经过编译的,具有执行计划,您可以对它们进行权限管理.
我不理解存储过程中的整个源代码控制问题.如果只是你有点自律,你绝对可以控制它们.
始终以.sql文件开头,该文件是存储过程的源.编写代码后,将其置于版本控制中.下次要编辑存储过程时,从源控件获取它而不是数据库.如果你遵循这个,你将拥有与你的代码一样好的源代码控制.
我想在这里引用Oracle的Tom Kyte ......这是他在编写代码的地方的规则......虽然有点无关但很好知道我猜.
从PL/SQL中的存储过程开始......
如果您认为使用PL/SQL中的存储过程无法完成某些操作,请使用Java存储过程.
如果您认为使用Java存储过程无法完成某些操作,请考虑使用Pro*c.
如果您认为使用Pro*C无法实现某些功能,您可能需要重新考虑完成所需的工作.
京公网安备 11010802040832号 | 京ICP备19059560号-6 