一切都存储过程

Question

我与一位同事讨论了.NET应用程序(在SQL Server 2005数据库上)中存储过程(SP)的使用问题.[他有微软的背景和我的Java - 可能相关也可能不相关].

我必须插入在UI中捕获的数据.为此我会写一个SP并在.NET代码中使用它？这不是必需的,但使用SP的优点和缺点是什么？

另一种情况:

我正在维护一份城市名单.用户可以使用UI添加城市.如您所料,用户无法进入重复的城市.如果发生重复输入,将显示错误.这可以通过多种方式实现:

1. 在我的代码中运行一个select查询以检查它是否已经存在,然后如果没有插入该城市,否则在UI上出现错误.
2. 直接插入并由于唯一索引SQLException将被捕获​​.反省SQLException以检查违反了哪个唯一索引并显示相应的错误.
3. 创建一个SP并在其中处理上述逻辑,即检查重复和抛出错误或插入

哪一个是正确的方法？(欢迎链接到良好的资源).

Answer 1

首先,使用SP而不是adhoc SQL语句是一个好主意,因为:1)安全性 - 只需要授予执行sproc的权限,而不是基础表2)可维护性 - 可以在SQL Server中修补SP而无需重建/部署.NET代码以调整查询3)性能 - 使用sprocs时执行计划缓存/重用提高了性能(如果在.NET中使用参数化SQL,也可以完成)4)网络流量(好的,可以忽略不计)但SP可以节省您通过网络传递整个SQL语句,尤其是在大型查询时)

例外是昂贵的,所以尽量避免在可以阻止异常时抛出异常.我建议在尝试插入记录之前编写一个执行IF EXISTS检查的sproc,如果不存在则只插入.只需返回一个返回代码或输出参数,指示发生了什么.例如0 =插入OK,-1 =已经存在

在一个sproc调用中完成所有操作以保存数据库往返(即不首先查询数据库以进行检查,然后发送另一个语句来执行INSERT).使用EXISTS检查是最佳的检查方式.

Answer 2

作为一般经验法则,如果应用程序是给定数据库模式的唯一用户,那么我建议使用直接SQL(即没有SP).如果数据库在应用程序之间共享,则控制应用程序和共享数据之间的接口变得更加重要,定义此接口的最简单方法是通过存储过程控制对数据的访问.

SP的使用增加了系统的复杂性,除非有充分的理由,否则不应增加复杂性.它还会严重妨碍您的应用程序使用优秀的ORM工具.

但与所有经验法则一样,总有例外.

Answer 3

我喜欢分离数据层和业务逻辑层的想法.因此,我没有将任何业务逻辑放在数据库中,而是放在我的域中的代码中.

如果你正在使用像NHibernate这样的ORM,数据库的角色将自动成为一个存储而不是别的.当您开始在数据库和应用程序的另一部分上实现业务逻辑的一部分时,您需要小心!

最好的祝福