【发布时间】：2011-06-23 21:53:22
【问题描述】：
我正在开发一个用于搜索的网页。我有两个选项来构建这个页面
根据用户输入的参数在页面上构建查询并发送给服务器。
将参数发送到存储过程并在那里构建查询并执行。
我想知道我应该采用哪种方法以及为什么。
我想知道这两种方法的优缺点。
【问题讨论】：
标签： .net sql sql-server sql-server-2005
【发布时间】：2011-06-23 21:53:22
【问题描述】：
如果查询只被少量使用，即席查询可能是一种选择。在几乎所有其他情况下，最好使用存储过程。
还可以考虑将optimize for ad hoc workloads option 设置为1。以下来自msdn
优化即席工作负载选项用于提高包含许多一次性即席批处理的工作负载的计划缓存效率。当此选项设置为 1 时，数据库引擎会在第一次编译批处理时在计划缓存中存储一个小的编译计划存根，而不是完整的编译计划。这有助于通过不允许计划缓存被未重用的已编译计划填充来缓解内存压力。
参考资料：
【讨论】：
通过使用 SQL 查询，我们实际上在可能更改的代码中公开了我们的数据库设计模式（设计）。所以我们使用存储过程，它是预编译的可执行对象，可以包含一个或多个 sql 语句。因此，存储过程是复杂 SQL 语句的副本。可以编写一个存储过程来接受输入并返回输出。
【讨论】：
从我这边存储过程会很好。
存储过程不会一次又一次地编译，简单查询每次都编译然后执行。
存储过程在服务器端执行，这就是它减少网络流量的原因。 SQL 查询也在服务器上执行，但如果您有大查询，则需要更多时间 与从客户端遍历到服务器的存储过程相比。
【讨论】：
我采用存储过程的方式，因为它易于维护和故障排除。
【讨论】：
通过从前端传递查询，增加了 sql 注入的机会。 存储过程是预先编译的，而查询首先编译而不是执行，因此语法错误的机会增加了
【讨论】：
使用存储过程。不是因为它们更快，而是因为它们强制与数据库签订合同（给存储的过程提供这些参数，它将返回数据）。
让应用决定如何处理数据，例如在 UI 中显示。让存储过程决定如何插入/更新/删除/检索数据。
跨多个前端重用存储过程中的查询/逻辑也容易得多。
【讨论】：
使用存储过程总是更好。
1) 如果您的查询很长，它将消耗您的网络资源。当我们通过网络连接发送大型 SQL 查询时，会增加网络流量。
2）存储过程是预编译和存储的，因此它们更快。
3）当你想修改查询时也很容易管理。
【讨论】：
-
1) 是的，是的； 2) 不抱歉，这是一个城市神话：一旦解析了一个临时查询并确定了一个查询计划，该查询计划就会被缓存和重用，随后对该临时查询的调用同样快 调用存储过程
-
1) 查询必须非常长才能使其成为一个因素。 2）这是一个神话（scarydba.com/2009/09/30/…）。 3) 这是非常主观的。
无论如何，我都不是数据库专家，但我的经验是，存储过程非常适合封装长期不会更改的固定查询。但它更难维护，至少在我做这件事的时候是这样，因为没有办法将存储过程保持在版本控制之下，并对服务器执行 rsync 之类的操作。因此，动态维护构建查询更容易，因为我可以在一个脚本或一组受修订控制的脚本中进行所有必要的更改。也许在这方面事情已经发生了变化，存储过程可以更好地与您的代码库集成；在这种情况下，存储过程可能会使您的代码更易于管理和维护。
【讨论】：