有关实现SQL存储过程的最佳实践建议（在C＃winforms应用程序中）是什么？

Question

我已经阅读了关于SQL存储过程的这些非常好的问题：

• When should you use stored procedures?和
• Are Stored Procedures more efficient, in general, than inline statements on modern RDBMS’s?

我是集成.NET / SQL的初学者，虽然我在其他环境中使用了十多年的基本SQL功能。现在是时候进行组织和部署了。我正在使用.NET C＃3.5，Visual Studio 2008和SQL Server 2008;虽然这个问题可以被视为与语言和数据库无关，但这意味着它可以轻松应用于使用存储过程和关系数据库的其他环境。

鉴于我有一个内联SQL查询的应用程序，并且我有兴趣转换为存储过程以实现组织和性能目的，您有什么建议这样做？

以下是我脑海中与此主题相关的一些其他问题，可能有助于形成答案：

• 我应该使用SQL Management Studio在SQL中创建存储过程，只需在为客户端安装数据库时重新创建数据库吗？
• 我最好在数据库初始化方法中创建应用程序中的所有存储过程吗？
• 假设创建存储过程必须遵循新安装中的表创建似乎是合乎逻辑的。我的数据库初始化方法创建新表并插入一些默认数据。我的计划是在该步骤之后创建存储过程，但我开始认为可能有更好的方法从头开始设置数据库（例如在程序的安装程序中）。对此的想法表示赞赏。
• 我在整个应用程序中都有各种各样的查询。有些查询非常简单（SELECT id FROM table），而其他查询非常冗长和复杂，执行多个连接并接受大约80个参数。我应该用存储过程替换所有查询，还是只替换那些可能从中受益的查询？
• 最后，由于这个主题显然需要一些研究和教育，你能否推荐一篇涵盖使用存储过程而不是直接陈述的细微差别的文章，书籍或教程？

Answer 1

考虑跳过ORM的存储过程。考虑使用：

• LINQ To SQL
• Entity Framework

• SubSonic

• 当您为应用程序添加更多价值时，您将编写较少的样板ListCustomer和GetCustomerByID代码。

• IMO，没有任何真正令人信服的理由选择我们在Microsoft堆栈中使用的现代工具集存储过程。

• 远离内联SQL语句是好的，ORM将帮助您为您的查询参数化。你不必考虑它。

• 您根本不必弄乱ADO.NET对象。以面向对象的方式对数据访问进行编码。

Answer 2

有几个令人信服的理由可以避免为很多登录提供表访问权限，包括应用程序登录，这些都会驱动存储过程的使用。 （出于性能原因，我通常不会认为使用SP很重要 - SQL Server甚至可以缓存特殊查询计划。）

存储过程为您的数据库提供了更多定义其接口边界的功能。在许多情况下，视图不足以控制界面。

任何仅基于表和视图构建的框架（请注意，许多框架可以构建在SP结果之上）在让数据库保护自身并控制自身方面将受到严重限制。

作为一个简单的例子，表和视图都不能参数化。如果您有一个非常大的表或视图，并且您希望强制所有用户指定一组特定的过滤条件（例如快照日期或生效日期），则无法在数据库调用接口强制执行此操作。框架可以一直提交查询。如果未公开表/视图，并且唯一的接口是通过SP或表值UDF，那么将提供该SP或UDF的参数必须，从而满足您的数据库需要确保它使用得当。

视图可能有效或无效的其他示例包括隐藏某些用户的隐私信息，隐藏内部密钥，隐藏内部实现细节以及实施复杂的安全规则。

至于脚本化数据库模式的创建，包括正确依赖顺序的对象，有几个工具可以执行此操作（并生成更改脚本），包括Red Gate SQL Compare和Apex SQLScript。

Answer 3

如果您真的有性能要求，请使用存储过程，特别是如果每​​分钟调用一次存储过程数千次。这样sql引擎避免了处理语句的几个步骤。 GPS跟踪系统就是一个例子。假设您有10000辆车，每分钟报告3个位置。在这种情况下，存储过程有助于提高性能。

如果不是，请使用ORM功能代替CRUD sql语句。

Answer 4

你错过了一个：

When is it better to write "ad hoc sql" vs stored procedures

我的回答是：根本不使用存储过程。