这是使用嵌入式SQL而不是存储过程的有效好处吗？

Question

这是我没有听说过SP的争论。褶皱，温柔的下颚，

由于每次访问数据库服务器都会产生开销，因此我建议将SQL放在SP中的可能原因是嵌入式代码更容易在不影响性能的情况下进行更改。

例如。假设您需要执行返回标量整数的查询A.

然后，之后，需求会发生变化，您可以确定标量的结果是＆gt; x然后，只有这时，您需要执行另一个查询。如果您在SP中执行了第一个查询，则可以轻松检查第一个查询的结果，并在同一个SP中有条件地执行第二个SQL。

如何在嵌入式SQL中有效地执行此操作，而不执行单独的查询或不必要的查询？

以下是一个例子：

--This SP may return 1 or two queries. 

SELECT @CustCount = COUNT(*) FROM CUSTOMER 

IF @CustCount > 10 
   SELECT * FROM PRODUCT 

这可以/在嵌入式SQL中执行此操作的最佳方式是什么？

Answer 1

A very persuasive article

SQL和存储过程将在您的数据持续时间内存在。

客户端语言来来去去，每次都必须重新实现嵌入式SQL。

Answer 2

在您提供的示例中，节省的时间是通过网络发送单个标量值和单个后续查询。在任何合理的情况下，这都是微不足道的。这并不是说使用SP可能没有其他有效的性能原因;只是这不是一个原因。

Answer 3

我通常不会将业务逻辑放在SP中，我希望它们在数据库之外以我的母语选择。我同意SP更好的唯一一次是当有大量数据移动不需要从数据库中出来时。

所以，为了回答你的问题，我宁愿在我的代码中有两个查询，而不是在SP中嵌入，在我看来，我的交易是一个小的性能点击更清楚的东西。

Answer 4

  

你将如何有效地做到这一点   嵌入式SQL没有单独执行   查询或不必要的查询？

取决于您使用的数据库。在SQL Server中，这是一个简单的CASE语句。

Answer 5

也许在该sproc中包含WHERE子句：

WHERE (all your regular conditions)
AND   myScalar > myThreshold

Answer 6

SP的好处：

1. 性能（预编译）
2. 易于更改（无需编译应用程序）
3. 基于SQL集的功能可以轻松完成非常困难的数据任务

缺点：

1. 严重依赖于使用的数据库引擎
2. 使升级部署更加困难（您必须部署App +脚本）

我的2美分......

关于您的示例，可以这样做：

select * from products where (select count(*) from customers>10)

Answer 7

最近我更喜欢不使用SP（除非出现uber复杂性，其中proc会更好......或者CLR会更好）。我一直在使用带有LINQ to SQL的Repository模式，其中我的查询在我的数据层中以强类型LINQ表达式编写。这里的关键是查询是强类型的，这意味着当我重构时，我正在重构一个直接从数据库表生成的类的属性（这使得DB的更改一直向前移动超级简单和准确）。虽然我的SQL是为我生成并发送到服务器的，但我仍然可以选择遵循DRY原则，因为存储库模式允许我将其分解为最小的组件。我确实有一个问题，我可能会去服务器，根据查询的结果，我可能会发现我需要再次访问服务器。我不担心这个问题。如果我后来发现它成为一个问题，那么我可以将该代码重构为更高效的代码。这里的全部关键是没有一个魔法子弹。我倾向于使用绿地应用程序，这使我的开发方法最有效。